Bug#1072962:
Control: forwarded -1 https://groups.google.com/g/efibootguard-dev/c/N4YhLFVCrx4 Control: tags -1 + fixed-upstream There is a fix available upstream at https://groups.google.com/g/efibootguard-dev/c/_eipQLxcNcc which I have tested with gnu-efi/compilers from unstable.
Bug#1072962: efibootguard kernel stub fails to boot
Hi again, On Tue, 2024-06-11 at 09:17 +0100, Christopher Obbard wrote: > Hi Jan, > > On Tue, 2024-06-11 at 07:10 +0200, Jan Kiszka wrote: > > Chris, you could check if already the vanilla stub fails to run as EFI > > binary. It should at least print "Unified kernel stub (EFI Boot Guard > > v0.17)" and "Missing .kernel section" when there is no kernel linked to > > it. This is to rule out potential problems of the bg_gen_unified_kernel > > script. > > Launching the kernel stub binary directly in qemu (v8.2.4) using the command > in my original message, the stub seems to attempt to print something to the > EFI console, but it ends up showing as many characters of whitespace and > simply quitting after 5s. > > I guess this shows the bg_gen_unified_kernel script is OK and the issue > falls > in the stub? > > For the record, the efibootguard binary itself seems to work just fine. I also built efibootguard v0.13 (e.g the version which works in bookworm) in my local debian unstable environment. The built kernel stub fails in the same way I reported. So I believe this narrows things down to the cross-compiler, some library or something else in the environment. Thanks!
Bug#1072962: efibootguard kernel stub fails to boot
Hi Jan, On Tue, 2024-06-11 at 07:10 +0200, Jan Kiszka wrote: > Chris, you could check if already the vanilla stub fails to run as EFI > binary. It should at least print "Unified kernel stub (EFI Boot Guard > v0.17)" and "Missing .kernel section" when there is no kernel linked to > it. This is to rule out potential problems of the bg_gen_unified_kernel > script. Launching the kernel stub binary directly in qemu (v8.2.4) using the command in my original message, the stub seems to attempt to print something to the EFI console, but it ends up showing as many characters of whitespace and simply quitting after 5s. I guess this shows the bg_gen_unified_kernel script is OK and the issue falls in the stub? For the record, the efibootguard binary itself seems to work just fine. Thanks Chris
Bug#1072962: efibootguard kernel stub fails to boot
Package: efibootguard Version: 0.17-2 Severity: important X-Debbugs-Cc: chris.obb...@collabora.com, efibootguard-...@googlegroups.com Dear Maintainer, efibootguard kernel-stub 0.17 from unstable fails to boot. kernel stub version 0.13 built in debian stable works fine. Minimal reproduction case (on amd64, using Distro kernel, but a mainline kernel built with CONFIG_EFI_STUB also fails): $ bg_gen_unified_kernel \ /usr/lib/x86_64-linux-gnu/efibootguard/kernel-stubx64.efi \ /boot/vmlinuz-6.8.12-amd64 \ linux.efi $ qemu-system-x86_64 \ -bios /usr/share/ovmf/OVMF.fd \ -m 2048M \ -drive format=raw,file=fat:rw:$(pwd) .. wait for the system to boot to an EFI shell & attempt to run linux.efi from the cwd. For the non-working case, there is no shell output at all, even the version print from the Kernel stub. Perhaps this is some kind of toolchain/library issue? I am getting similar issues when building the kernel stub from source manually using a toolchain built by buildroot. If you have any hints on what to try next, it'd be helpful. I was going to try to build 0.17 in a Debian stable container, as a next step, to attempt to see if it is a toolchain/gnu-efi library issue. Thanks, Chris -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages efibootguard depends on: ii libc62.38-12.1 ii python3 3.11.8-1 efibootguard recommends no packages. efibootguard suggests no packages. -- no debconf information
Bug#1071222: mesa: FTBFS due to missing build dependency python3-pycparser
Source: mesa
Version: 24.1.0~rc3-1
Severity: minor
Tags: ftbfs
Dear Maintainer,
On my local machine, mesa FTBFS unless I install python3-pycparser:
Running command: /usr/bin/python3 -c '
try:
from packaging.version import Version
except:
from distutils.version import StrictVersion as Version
import pycparser
assert Version(pycparser.__version__) >= Version("2.20")
'
--- stdout ---
--- stderr ---
Traceback (most recent call last):
File "", line 6, in
ModuleNotFoundError: No module named 'pycparser'
../src/etnaviv/hwdb/meson.build:17:2: ERROR: Problem encountered: Python
(3.x) pycparser module >= 2.20 required to build mesa.
It seems to install the dependency and build fine on Debian buildd, so
marking the bug as minor. Since this package seems to be a direct
dependency for the etnaviv hwdb bits, I think we should add
python3-pycparser as a direct build depends.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1070788: mesa: Package teflon - TensorFlow Lite delegate library
Hi, [+Timo and X team] On Thu, 09 May 2024 08:42:54 +0100 Christopher Obbard wrote: > Source: mesa > Version: 24.1.0~rc2-1 > Severity: wishlist > X-Debbugs-Cc: obba...@debian.org, to...@tomeuvizoso.net > > Dear Maintainer, > > Mesa 24.1 contains a TensorFlow Lite delegate that can make use of NPUs > to accelerate ML inference. It is implemented in the form of a external > delegate, a shared library that the TensorFlow Lite runtime can load at > startup[0]. > > We should consider packaging this for users. > > It should be a matter of just passing -Dteflon=true to the build config > > Since it builds a shared library, libteflon.so, we should package this > as a separate library. How does libteflon0 sound? > > We can use a description similar to the first paragraph, which has been > taken from [1]. > > I will prepare a merge request on Salsa for this over the coming weeks. I've made an initial implementation for the packaging for the Teflon library at https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/39 Reviews welcome! Thanks, Chris
Bug#1070788: mesa: Package teflon - TensorFlow Lite delegate library
Source: mesa Version: 24.1.0~rc2-1 Severity: wishlist X-Debbugs-Cc: obba...@debian.org, to...@tomeuvizoso.net Dear Maintainer, Mesa 24.1 contains a TensorFlow Lite delegate that can make use of NPUs to accelerate ML inference. It is implemented in the form of a external delegate, a shared library that the TensorFlow Lite runtime can load at startup[0]. We should consider packaging this for users. It should be a matter of just passing -Dteflon=true to the build config Since it builds a shared library, libteflon.so, we should package this as a separate library. How does libteflon0 sound? We can use a description similar to the first paragraph, which has been taken from [1]. I will prepare a merge request on Salsa for this over the coming weeks. [0]: https://www.tensorflow.org/api_docs/python/tf/lite/experimental/load_delegate. [1]: https://docs.mesa3d.org/teflon.html Thanks! Chris -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055618: taking over maintainance of swugenerator & python-libconf
Hi Bastian, I'm interested in taking over the long-term maintenance of swugenerator (& dependant package python-libconf). I will kick this off by importing version 0.4 of swugenerator & backporting to bookworm-backports (I have a need to use the latest version in debian stable). Can you please give me access (obbardc on salsa) to the package repository on salsa ? Thank you ! Chris
Bug#1069273: ITP: gnome-shell-extension-tactile -- Tile windows on a custom grid using your keyboard
Hi, This looks very useful. I'd gladly sponsor an upload. On Fri, 19 Apr 2024, 08:45 David Edmondson, wrote: > Package: wnpp > Severity: wishlist > Owner: David Edmondson > X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dme.org > > * Package name: gnome-shell-extension-tactile > Version : 32 > Upstream Contact: Per Thomas Lundal, https://gitlab.com/lundal > * URL : https://gitlab.com/lundal/tactile > * License : GPL-3+ > Programming Lang: Javascript, Typescript > Description : Tile windows on a custom grid using your keyboard > > > Type Super-T to show the grid, then type two tiles (or the same tile > > twice) to move the active window. > > > > The grid can be up to 4x3 (corresponding to one hand on the keyboard) > > and each row/column can be weighted to take up more or less space. > > I've been using Tactile for a few years now and find it indispensable > for managing windows on a larger monitor with GNOME. > > I'm eager to maintain the package in Debian and will need a sponsor. > >
Bug#1032659: ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.
Hi,
I have done the packaging (from Mark's existing packaging, thank you!) for the
new version 3.0.0. I hope to upload to the NEW queue tomorrow; but first I
need to get the Git repo in good shape.
@Mark, I made slight changes to the packaging but you are still marked as an
Uploader alongside me, I have left your copyright in d/copyright, and your
packaging commit authorship is in d/changelog. I hope that is acceptable by
you :-)?
@Go Team, Can I have maintainer access to
https://salsa.debian.org/go-team/packages/golang-github-go-task-slim-sprig ?
Currently I am just developer on that repo, it'd be great to get full access
so I can modify CI setting etc.
Thanks!
Chris
On Wed, 2024-01-10 at 17:24 +, Christopher Obbard wrote:
> Hi Mark,
>
> Did you think about my comments below? I would like to upload this package
> into the NEW queue over the next couple of weeks (so to not block a new
> imminent version of debos from being included in the archive).
>
> Please do let me know if you have time to make the changes, or alternatively
> if you do not have the time. I can make the changes to the packaging, but I
> do
> not want to duplicate effort.
>
> Thanks!
> Chris
>
> On Thu, 2023-12-07 at 18:57 +, Christopher Obbard wrote:
> > Hi Mark,
> >
> > I will be willing to sponsor this package (mainly as I am looking to using
> > it
> > in Debos). Your packaging looks generally good, but I have noticed a few
> > minor
> > issues with the Git repo / packaging, let me know if you can fix these or
> > if
> > you'd like me to do so.
> >
> > - d/copyright: "Copyright: 2019 Task" seems.. wrong? Also, for the record
> > there is no explicit licence file in the upstream repository, but the
> > GitHub
> > page says MIT.
> >
> > - The package's commit history seems to modify the original source, e.g.
> > 908e6bca ("Ignore _build and quilt .pc dirs via .gitignore") which is then
> > reverted by af533953 ("Import Debian changes 2.20.0-1"). It would be far
> > cleaner to drop these commits.
> >
> > - 6ef11ba6 ("fixup: unstable build submission") seems to be wrong. As
> > you're
> > not uploading into unstable, you should leave it as UNRELEASED.
> >
> > - v3.0.0 has been released upstream. What would the plan be for importing
> > that?
> >
> > - The TestShuffle function seems to fail (heh, is this test even
> > deterministic
> > ?):
> >
> > > $ gbp buildpackage --git-pbuilder
> > > === RUN TestShuffle
> > > functions_test.go:82:
> > > Error Trace:/build/golang-github-go-task-slim-
> > > sprig-
> > > 2.20.0/_build/src/github.com/go-task/slim-sprig/functions_test.go:82
> > > Error: Received unexpected error:
> > > Expected 'rldo HWlloe', got 'olldolr
> > > WeH'
> > > Test: TestShuffle
> > > --- FAIL: TestShuffle (0.00s)
> > >
> > > dh_auto_test: error: cd _build && go test -vet=off -v -p 16
> > > github.com/go-
> > > task/slim-sprig returned exit code 1
> >
> >
> >
> > Thanks!
> >
> > Chris
Bug#1032659: ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.
Hi Mark,
Did you think about my comments below? I would like to upload this package
into the NEW queue over the next couple of weeks (so to not block a new
imminent version of debos from being included in the archive).
Please do let me know if you have time to make the changes, or alternatively
if you do not have the time. I can make the changes to the packaging, but I do
not want to duplicate effort.
Thanks!
Chris
On Thu, 2023-12-07 at 18:57 +, Christopher Obbard wrote:
> Hi Mark,
>
> I will be willing to sponsor this package (mainly as I am looking to using
> it
> in Debos). Your packaging looks generally good, but I have noticed a few
> minor
> issues with the Git repo / packaging, let me know if you can fix these or if
> you'd like me to do so.
>
> - d/copyright: "Copyright: 2019 Task" seems.. wrong? Also, for the record
> there is no explicit licence file in the upstream repository, but the GitHub
> page says MIT.
>
> - The package's commit history seems to modify the original source, e.g.
> 908e6bca ("Ignore _build and quilt .pc dirs via .gitignore") which is then
> reverted by af533953 ("Import Debian changes 2.20.0-1"). It would be far
> cleaner to drop these commits.
>
> - 6ef11ba6 ("fixup: unstable build submission") seems to be wrong. As you're
> not uploading into unstable, you should leave it as UNRELEASED.
>
> - v3.0.0 has been released upstream. What would the plan be for importing
> that?
>
> - The TestShuffle function seems to fail (heh, is this test even
> deterministic
> ?):
>
> > $ gbp buildpackage --git-pbuilder
> > === RUN TestShuffle
> > functions_test.go:82:
> > Error Trace:/build/golang-github-go-task-slim-sprig-
> > 2.20.0/_build/src/github.com/go-task/slim-sprig/functions_test.go:82
> > Error: Received unexpected error:
> > Expected 'rldo HWlloe', got 'olldolr WeH'
> > Test: TestShuffle
> > --- FAIL: TestShuffle (0.00s)
> >
> > dh_auto_test: error: cd _build && go test -vet=off -v -p 16 github.com/go-
> > task/slim-sprig returned exit code 1
>
>
>
> Thanks!
>
> Chris
Bug#1032659: ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.
Hi Mark,
I will be willing to sponsor this package (mainly as I am looking to using it
in Debos). Your packaging looks generally good, but I have noticed a few minor
issues with the Git repo / packaging, let me know if you can fix these or if
you'd like me to do so.
- d/copyright: "Copyright: 2019 Task" seems.. wrong? Also, for the record
there is no explicit licence file in the upstream repository, but the GitHub
page says MIT.
- The package's commit history seems to modify the original source, e.g.
908e6bca ("Ignore _build and quilt .pc dirs via .gitignore") which is then
reverted by af533953 ("Import Debian changes 2.20.0-1"). It would be far
cleaner to drop these commits.
- 6ef11ba6 ("fixup: unstable build submission") seems to be wrong. As you're
not uploading into unstable, you should leave it as UNRELEASED.
- v3.0.0 has been released upstream. What would the plan be for importing
that?
- The TestShuffle function seems to fail (heh, is this test even deterministic
?):
> $ gbp buildpackage --git-pbuilder
> === RUN TestShuffle
> functions_test.go:82:
> Error Trace:/build/golang-github-go-task-slim-sprig-
> 2.20.0/_build/src/github.com/go-task/slim-sprig/functions_test.go:82
> Error: Received unexpected error:
> Expected 'rldo HWlloe', got 'olldolr WeH'
> Test: TestShuffle
> --- FAIL: TestShuffle (0.00s)
>
> dh_auto_test: error: cd _build && go test -vet=off -v -p 16 github.com/go-
> task/slim-sprig returned exit code 1
Thanks!
Chris
Bug#1056592: debos: yaml: line X: did not find expected key
Hi Arnaud, On Fri, 2023-11-24 at 09:48 +0700, Arnaud Rebillout wrote: > > I think this has something to do with the recent shell escaping patches. > > Perhaps there is some go module which isn't up to date in Debian causing > > the > > additional single quotation marks around the inner debos call ? > > > Indeed, the package golang-github-alessio-shellescape is not exactly at the > last version in Debian, we have 1.4.1, upstream is at 1.4.2. > > However, after updating it, and rebuilding the fakemachine package, and then > rebuilding debos, I still have the same error. > > After digging a bit more, I found that Sjoerd added a few commits to debos, > just after release 1.1.2. Those commits are needed if fakemachine 0.0.7 is > used, and I can confirm that the issue is fixed by importing those commits. > Cf: https://salsa.debian.org/go-team/packages/debos/-/merge_requests/5 Oh, turns out I completely forgot about that. I think it makes sense to release a new upstream Debos version, import that into Debian and drop your merge request. I will do that today. > Packaging sidenote: please push your pristine-tar branch (or disable it in > debian/gbp.conf), at the moment "gbp buildpackage" fails because of that. I did look on Salsa and the pristine-tar branches for both debos and golang- github-go-debos-fakemachine are up-to-date. As part of my update process I try to always call "gbp push" which pushes the pristine-tar branch, are you sure that is the problem here?
Bug#1056592: debos: yaml: line X: did not find expected key
Hi Arnaud,
On Thu, 2023-11-23 at 23:23 +0700, Arnaud Rebillout wrote:
> Package: debos
> Version: 1.1.2-2
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
>
> Hi Christopher,
>
> Here's a surprising bug report. The version of debos currently in Debian
> unstable is a bit broken, in an odd way.
>
> Consider the following recipe:
>
> ```
> $ cat main.yaml
> {{ $ospack := or .ospack "debian" }}
> architecture: amd64
> actions:
> - action: debootstrap
> suite: sid
> - action: pack
> file: {{ $ospack }}.tar.gz
> ```
>
> If I run with `-t ospack:debian` it fails:
>
> ```
> $ debos --print-recipe -t ospack:debian main.yaml
> 2023/11/23 23:05:27 Recipe '/home/user/debos/main.yaml':
> 2023/11/23 23:05:27
> architecture: amd64
> actions:
> - action: debootstrap
> suite: sid
> - action: pack
> file: debian.tar.gz
> Running /debos --artifactdir /home/user/debos --template-var
> 'ospack:"debian"' /home/user/debos/main.yaml using kvm backend
> 2023/11/23 16:05:31 yaml: line 6: did not find expected key
> ```
For me with debos 1.1.2-2, I seem to reproduce your issue:
Running /debos --artifactdir debos-tests --template-var 'ospack:"debian"'
debos-tests/test-key.yaml using kvm backend
2023/11/23 16:41:30 yaml: line 7: did not find expected key
But with a local checkout of debos upstream built with `go build`, your recipe
runs just fine (notice there are now no single-quotes around the --template-
var argument to the inner debos call):
Running /debos --artifactdir debos-tests --template-var ospack:debdfsa
debos-tests/test-key.yaml using kvm backend
2023/11/23 16:41:46 debootstrap
I think this has something to do with the recent shell escaping patches.
Perhaps there is some go module which isn't up to date in Debian causing the
additional single quotation marks around the inner debos call ?
> However if I run without `-t`, it succeeds:
>
> ```
> $ debos --print-recipe main.yaml
> 2023/11/23 23:10:55 Recipe '/home/user/debos/main.yaml':
> 2023/11/23 23:10:55
> architecture: amd64
> actions:
> - action: debootstrap
> suite: sid
> - action: pack
> file: debian.tar.gz
> Running /debos --artifactdir /home/user/debos /home/user/debos/main.yaml
> using kvm backend
> 2023/11/23 16:10:59 debootstrap
> 2023/11/23 16:10:59 Debootstrap | I: Target architecture can be executed
> 2023/11/23 16:10:59 Debootstrap | I: Retrieving InRelease
> [...]
> ```
>
> Another surprise: this is a regression introduced by package 1.1.2-2. If
> I downgrade to version 1.1.2-1, everything works fine.
>
> ```
> sudo apt install --allow-downgrades ./debos_1.1.2-1_amd64.deb
> ```
>
> I compared the Built-Using fields between both packages:
>
> ```
> -golang-1.21 (= 1.21.1-1)
> +golang-1.21 (= 1.21.4-1)
> +golang-github-alessio-shellescape (= 1.4.1-3)
> golang-github-cespare-xxhash (= 2.1.1-2)
> golang-github-docker-go-units (= 0.4.0-4)
> -golang-github-go-debos-fakemachine (= 0.0.6-1)
> +golang-github-go-debos-fakemachine (= 0.0.7-1)
> golang-github-google-uuid (= 1.3.0-1)
> -golang-github-klauspost-compress (= 1.15.12+ds1-3)
> +golang-github-klauspost-compress (= 1.17.2+ds1-1)
> golang-github-sjoerdsimons-ostree-go (= 0.0~git20201014.8fae757-2)
> golang-github-surma-gocpio (= 1.1.0+git20160926.fcb6877-1.1)
> golang-github-ulikunitz-xz (= 0.5.6-2)
> golang-go-flags (= 1.4.0-6)
> -golang-golang-x-sys (= 0.9.0-1)
> +golang-golang-x-sys (= 0.13.0-1)
> golang-gopkg-freddierice-go-losetup.v1 (= 0.0~git20170407.fc9adea-1.1)
> golang-yaml.v2 (= 2.4.0-4)
> ```
>
> I suppose the regression was introduced by one of the dependencies that
> changed. I have no idea how to troubleshot that... Tomorrow I'll try to
> rebuild a package to see if that magically fixes it.
>
> Can you try to reproduce this issue on your side, just to confirm?
>
> Thanks in advance,
>
> Arnaud
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages debos depends on:
> ii busybox 1:1.36.1-4
> ii debootstrap 1.0.133
> ii libc6 2.37-12
> ii libglib2.0-0 2.78.1-4
> ii libostree-1-1 2023.7-3
> ii qemu-system-x86 1:8.1.2+ds-1
> ii qemu-user-static 1:8.1.2+ds-1
> ii systemd-container 255~rc2-1
>
> Versions of packages debos recommends:
> ii bmap-tools 3.7-1
> ii bzip2 1.0.8-5+b1
> ii dosfstools 4.2-1
> ii e2fsprogs 1.47.0-2+b1
> ii fdisk 2.39.2-6
> ii linux-image-amd64 6.5.10-1
> ii mount 2.39.2-6
> ii ovmf 2023.05-2
> ii parted 3.6-3
> ii systemd-resolved
Bug#1054259: [Pkg-javascript-devel] Bug#1054259: nodejs: cannot bootstrap nodejs
Control: retitle -1 nodejs: cannot bootstrap nodejs Hi Jérémy, On Fri, 2023-10-20 at 02:25 +0200, Jérémy Lal wrote: > https://salsa.debian.org/js-team/nodejs/-/blob/master- > 18.x/debian/README.source Thanks for your suggestion. I actually did follow those instructions to attempt to build nodejs 18.13.0+dfsg1-1. For nodejs 16.15.1+dfsg-1 following those instructions bootstraps the package just fine, I think because the "externalized builtin" JS files are present in the packaging. I have attached the three patches to debian/ to get _something_ bootstrap for 18x but it still fails with the error "Cannot load externalized builtin" when trying to launch bootstrapped node. I build the package using debuild --no-lintian in a chroot. In the build system I have no ability to build arch:all packages, just architecture dependant packages. Thanks! > Le ven. 20 oct. 2023 à 01:27, Christopher Obbard > a écrit : > > Source: nodejs > > Version: 18.13.0+dfsg1-1 > > Severity: important > > X-Debbugs-Cc: chris.obb...@collabora.com > > > > Dear Maintainer, > > > > Bootstrapping nodejs version 18 FTBFS for me. There seems to be a couple > > of different issues when bootstrapping: > > > > 1) The created node binary fails with an error about the externalized > > builtins not being found. This renders the binary useless. This also > > causes an error in the bootstrap process, override_dh_auto_build-arch > > fails with: > > > > Cannot load externalized builtin: "internal/deps/cjs-module- > > lexer/lexer:/usr/share/nodejs/cjs-module-lexer/lexer.js". > > 1: 0x7f06454026cc node::Abort() [/mnt/_build/nodejs- > > 18.13.0+dfsg1/out/Release/libnode.so.108] > > 2: 0x7f06453e1f1d [/mnt/_build/nodejs- > > 18.13.0+dfsg1/out/Release/libnode.so.108] > > 3: 0x7f06453e2069 node::builtins::BuiltinLoader::BuiltinLoader() > > [/mnt/_build/nodejs-18.13.0+dfsg1/out/Release/libnode.so.108] > > 4: 0x7f064531db83 [/mnt/_build/nodejs- > > 18.13.0+dfsg1/out/Release/libnode.so.108] > > 5: 0x7f064782947e [/lib64/ld-linux-x86-64.so.2] > > 6: 0x7f0647829568 [/lib64/ld-linux-x86-64.so.2] > > 7: 0x7f06478432ca [/lib64/ld-linux-x86-64.so.2] > > Aborted (core dumped) > > > > > > 2) dh_install fails with: > > > > dh_install: warning: Cannot find (any matches for) > > "./<@(node_builtin_shareable_builtins)" (tried in ., debian/tmp) > > dh_install: warning: nodejs missing files: > > ./<@(node_builtin_shareable_builtins) > > dh_install: error: missing files, aborting > > > > > > I have a couple of patches which works around these issues and can create > > a bootstrapped nodejs (I can share my patches if that is useful); but the > > created binary is useless due to the "Cannot load externalized builtin" > > error. > > > > Thanks! > > > > -- System Information: > > Debian Release: trixie/sid > > APT prefers unstable > > APT policy: (500, 'unstable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_GB:en > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > Thanks! Chris From 8175c5f66df782c672df5b5a2a8d31eed915021b Mon Sep 17 00:00:00 2001 From: Christopher Obbard Date: Thu, 19 Oct 2023 14:38:26 +0100 Subject: [PATCH 1/9] Set build profiles to bootstrap nodejs Signed-off-by: Christopher Obbard --- debian/control | 74 +- debian/rules | 2 ++ 2 files changed, 39 insertions(+), 37 deletions(-) diff --git a/debian/control b/debian/control index d1966836..4f12726c 100644 --- a/debian/control +++ b/debian/control @@ -6,13 +6,13 @@ Uploaders: Jérémy Lal , Jonas Smedegaard Build-Depends: gcc-11, g++-11, - sse2-support [i386] , - armv6k-support [armel] , vfpv2-support [armel] , +# sse2-support [i386] , +# armv6k-support [armel] , vfpv2-support [armel] , debhelper-compat (= 13), dh-buildinfo, bash-completion, ca-certificates, - curl , +# curl , gyp (>= 0.1~svn1773), jq, libbrotli-dev, @@ -29,21 +29,21 @@ Build-Depends: libssl-dev:native, libuv1-dev (>= 1.43.0~), libuv1-dev:native, - node-acorn (>= 6.2.1~) , - node-cjs-module-lexer (>= 1.2.2~) , - node-undici (>= 5.0.0~) , - openssl (>= 1.1.1~) , +# node-acorn (>= 6.2.1~) , +# node-cjs-module-lexer (>= 1.2.2~) , +# node-undici (>= 5.0.0~) , +# openssl (>= 1.1.1~) , pkg-config, - pkg-js-to
Bug#1054259: nodejs: cannot bootstrapped nodejs
Source: nodejs Version: 18.13.0+dfsg1-1 Severity: important X-Debbugs-Cc: chris.obb...@collabora.com Dear Maintainer, Bootstrapping nodejs version 18 FTBFS for me. There seems to be a couple of different issues when bootstrapping: 1) The created node binary fails with an error about the externalized builtins not being found. This renders the binary useless. This also causes an error in the bootstrap process, override_dh_auto_build-arch fails with: Cannot load externalized builtin: "internal/deps/cjs-module-lexer/lexer:/usr/share/nodejs/cjs-module-lexer/lexer.js". 1: 0x7f06454026cc node::Abort() [/mnt/_build/nodejs-18.13.0+dfsg1/out/Release/libnode.so.108] 2: 0x7f06453e1f1d [/mnt/_build/nodejs-18.13.0+dfsg1/out/Release/libnode.so.108] 3: 0x7f06453e2069 node::builtins::BuiltinLoader::BuiltinLoader() [/mnt/_build/nodejs-18.13.0+dfsg1/out/Release/libnode.so.108] 4: 0x7f064531db83 [/mnt/_build/nodejs-18.13.0+dfsg1/out/Release/libnode.so.108] 5: 0x7f064782947e [/lib64/ld-linux-x86-64.so.2] 6: 0x7f0647829568 [/lib64/ld-linux-x86-64.so.2] 7: 0x7f06478432ca [/lib64/ld-linux-x86-64.so.2] Aborted (core dumped) 2) dh_install fails with: dh_install: warning: Cannot find (any matches for) "./<@(node_builtin_shareable_builtins)" (tried in ., debian/tmp) dh_install: warning: nodejs missing files: ./<@(node_builtin_shareable_builtins) dh_install: error: missing files, aborting I have a couple of patches which works around these issues and can create a bootstrapped nodejs (I can share my patches if that is useful); but the created binary is useless due to the "Cannot load externalized builtin" error. Thanks! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3
On Thu, 2023-10-12 at 13:11 +0200, Michael Biebl wrote: > On Wed, 20 Sep 2023 21:41:59 +0200 Michael Biebl wrote: > > FYI: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/216 > > > > To mitigate this issue for the time being, I suggest we simply remove > /usr/lib/kernel/install.d/60-ukify.install from the systemd package (or > ship in /usr/share/doc/systemd/examples, so users could copy it to > /etc/kernel/install.d/) For what it may be worth, that sounds sensible to me as we don't use ukify as yet. Do we have any plans to enable that for trixie we could work on as a follow-up ? > > Splitting off systemd-ukify turns out to be a larger change and with the > /usr merge change going on, maybe something we want to avoid/postpone. > > Michael
Bug#971920: nextcloud-desktop: Not showing tray icon on Xfce
Hi Hefee, Unfortunately I now have switched to gnome-shell where this bug is no longer reproducible for me and I don't have the time to reinstall xfce4 to try again. Thanks! On Tue, 10 Oct 2023 at 00:32, Hefee wrote: > > Control: tags -1 moreinfo upstream > > Hey, > > Sorry, I did overseen the bugreport and didn't come back in time. > > if it still is valid under the new version? > > What protocol does XFCE is using for tray icons. At least am aware that GNOME > appidicator has for some users issues displaying tray icons: > https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/232 > > But there are more bugs on upstream about issues with tray icon. Please look > there maybe a matching bug report is already there: > https://github.com/nextcloud/desktop/issues > > If you found a corresponding upstream bug or create a new issue > Please report back the url, than we can keep track of the upstream bug. > > @chris: About the empty window. Maybe: > https://github.com/nextcloud/desktop/issues/5443 > https://github.com/nextcloud/desktop/issues/4602 > > if you are using wayland is qtwayland5 installed? > > Regards, > > hefee > > On Freitag, 9. Oktober 2020 21:09:23 CEST Christopher Obbard wrote: > > For me on XFCE the tray icon appears but clicking on it does nothing. One > > has to right click and go to settings for it to open > > > > Thanks! > > Chris >
Bug#1050969:
There is some work pending upstream before we can really ship this in Debian: https://gitlab.com/larswirzenius/v-i/-/issues/35#note_1552156798
Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3
Hi Michael, On Fri, 2023-09-15 at 11:42 +0200, Michael Biebl wrote: > Am 15.09.23 um 11:06 schrieb Christopher Obbard: > > Package: src:systemd > > Version: 254.1-3 > > Severity: important > > X-Debbugs-Cc: chris.obb...@collabora.com > > > > Dear Maintainer, > > > > Installing a new kernel on a system which uses systemd-boot as the > > bootloader fails if python3 is not installed. Here's the snippet from apt > > upgrade: > > > > /etc/kernel/postinst.d/zz-systemd-boot: > > Installing kernel version 6.4.0-4-amd64 in systemd-boot... > > /usr/bin/env: ‘python3’: No such file or directory > > /usr/lib/kernel/install.d/60-ukify.install failed with exit status 127. > > > > This renders the new kernel unusable as it never actually gets installed > > in the right place for systemd-boot. > > > > /etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn > > calls /usr/lib/kernel/install.d/60-ukify.install which calls > > /lib/systemd/ukify > > to attempt to create a unified kernel image. These are both python3 scripts. > > > > To workaround this, I have deleted > > /usr/lib/kernel/install.d/60-ukify.install > > as we don't (yet!) create uki images with the ukify utility anyway. When > > the ukify postinst script _does_ run, it currently just detects the > > environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config > > files) and exits early, not even creating the uki. So this is opt-in. > > > > /lib/systemd/ukify is shipped in the systemd package along with > > /usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as > > systemd package does not have the right dependencies for this script. > > > > > > Perhaps we should split the ukify bits into its own package (systemd-ukify) > > which depends on python3 and should be manually installed? Also this package > > can then depend on e.g. sbsigntool and other packages to actually manage > > the signing (but that can be a separate bug!). > > > > Having a separate package feels a bit like overkill for 68K > > 52K /lib/systemd/ukify > 8,0K /usr/lib/kernel/install.d/60-ukify.install > 8,0K /usr/share/man/man1/ukify.1.gz > > > While systemd has a suggests python3, we certainly don't want a hard > python3 dependency though. > A possible middle way could be to implement > /usr/lib/kernel/install.d/60-ukify.install in shell, the script seems > simple enough. Thank you for your reply & suggestion. I don't think that overriding this script manually in the Debian package is a good idea as I think that just diverges from upstream's scripts. Also, just because the script is small I don't think that should mean it should be shipped as part of systemd and not its own package. Maybe I am missing some reasoning here? Since the ukify script is designed to build a unified kernel image and also sign the unified kernel image using e.g. sbsign, I think it should go into its own package so it can depend on python3 and the required signing tools and users can manually install it if they want to build ukis. By default users will probably not need to build ukis yet. Also, Fedora and Arch seem to also package this script separately as systemd-ukify. I can write a patch to do this, of course, I just would like some clarification on the way forward first. Thanks! Chris.
Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3
Package: src:systemd Version: 254.1-3 Severity: important X-Debbugs-Cc: chris.obb...@collabora.com Dear Maintainer, Installing a new kernel on a system which uses systemd-boot as the bootloader fails if python3 is not installed. Here's the snippet from apt upgrade: /etc/kernel/postinst.d/zz-systemd-boot: Installing kernel version 6.4.0-4-amd64 in systemd-boot... /usr/bin/env: ‘python3’: No such file or directory /usr/lib/kernel/install.d/60-ukify.install failed with exit status 127. This renders the new kernel unusable as it never actually gets installed in the right place for systemd-boot. /etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn calls /usr/lib/kernel/install.d/60-ukify.install which calls /lib/systemd/ukify to attempt to create a unified kernel image. These are both python3 scripts. To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install as we don't (yet!) create uki images with the ukify utility anyway. When the ukify postinst script _does_ run, it currently just detects the environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config files) and exits early, not even creating the uki. So this is opt-in. /lib/systemd/ukify is shipped in the systemd package along with /usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as systemd package does not have the right dependencies for this script. Perhaps we should split the ukify bits into its own package (systemd-ukify) which depends on python3 and should be manually installed? Also this package can then depend on e.g. sbsigntool and other packages to actually manage the signing (but that can be a separate bug!). Thanks! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-boot depends on: ii libc6 2.37-7 ii libsystemd-shared 254.1-3 ii systemd-boot-efi 254.1-3 Versions of packages systemd-boot recommends: ii efibootmgr 17-2 systemd-boot suggests no packages. -- no debconf information
Bug#1051324: efibootguard: Split into multiple packages
Source: efibootguard Version: 0.15-1 Severity: wishlist Dear Maintainer, The efibootguard package for amd64 ships the following binaries: - /usr/bin/bg_gen_unified_kernel - /usr/bin/bg_printenv - /usr/bin/bg_setenv - /usr/lib/x86_64-linux-gnu/efibootguard/efibootguardx64.efi - /usr/lib/x86_64-linux-gnu/efibootguard/kernel-stubx64.efi I think it makes sense to ship the efi binaries in the efibootguard package and to ship the host tools in a package named e.g. efibootguard-tools. It could even make sense to split bg_gen_unified_kernel into its own packages as it's not really a tool for the target? This bug really is wishlist level; I opened the bug to start a discussion about it. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1050968: ITP: rkbin -- Pre-built Rockchip bootloader firmware binaries (for embedded targets)
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-de...@lists.debian.org, chris.obb...@collabora.com Package name: rkbin Version : 0.0.0~git20230726.b4558da Upstream Contact: Kever Yang URL : https://github.com/rockchip-linux/rkbin License : Copyright © 2017-2023，Rockchip Electronics Co., Ltd. All rights reserved. Programming Lang: n/a; prebuilt firmware binaries Description : Pre-built Rockchip bootloader firmware binaries (for embedded targets) This package contains the Rockchip bootloader firmware binaries, primarily used for targets where no open-source versions is yet released. The pre-built firmware consists of builds of Arm Trusted Firmware, OP-TEE and U-Boot. There are also some closed-source tools in this repo, build for amd64. These will be stripped from the upstream source package as I do not (yet) see a need for these. This package is required to build U-Boot for some embedded targets such as rk3588, rk3566, rk3568. All of these will eventually have open-source firmware, but it is still useful for new processors in the future where U-Boot support will be merged long before the initial DRAM bringup and trusted firmware. I expect this package will go into non-free-firmware. If anyone rejects having this kind of package in Debian, please do reply to this message. I don't have any immediate plans to package this.
Bug#1050969: ITP: v-i -- An alternative Debian installer using vmdb2 and ansible
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-de...@lists.debian.org, chris.obb...@collabora.com Package name: v-i Version : 0.4 Upstream Contact: Lars Wirzenius URL : https://gitlab.com/larswirzenius/v-i License : GPL-3 Programming Lang: Python, YAML Description : An alternative Debian installer using vmdb2 and ansible v-i installs a very basic Debian onto a PC. It's entirely non-interactive and unhelpful. The author wrote it so that repeated installations would be less of a chore than using the official Debian installer. v-i uses vmdb2 to install onto bare metal hardware. vmdb2 is a program to create a disk image virtual machines with Debian, by the same author. It "installs Debian" to a file representing a hard drive. It's basically debootstrap, except the target is a disk image instead of a directory. It's used to create Debian images for Raspberry Pis. I'd like to package this as part of the installer-team, but I haven't yet asked their permission or had any grace from them.
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
Hi Diederik, On Thu, 2023-08-31 at 17:46 +0100, Christopher Obbard wrote: > Hi Diederik, > > To stay on-topic here, I also have a Pine64 Quartz64 model A - I'd be happy > to be added as a board maintainer in Debian. > > I didn't yet manage to build U-Boot mainline for it, see > https://lists.denx.de/pipermail/u-boot/2023-August/526625.html > I still owe a reply on that topic to Jonas' suggestions, I will hope to get > to that next week. > > > On Thu, 2023-08-31 at 17:50 +0200, Diederik de Haas wrote: > > > Sorry, our mails collided and I didn't see your previous reply. > > Ha! I thought about sending you a private mail about that, but chose not to > > as > > they weren't conflicting. > > No problem, on-list is probably best anyway so it is archived ;-) > > > > > On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote: > > > > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote: > > > So far so good ;-). The only clarification I would like to make is the DDR > > > init code is standalone, part of the TPL and is not anything to do with > > > TF-A. It really is the first-stage boot code that runs after the maskrom. > > > > > > We could use Rockchip's closed implementation of that OR U-Boot's > > > implementation, it's only real job is to train the DDR and handoff to > > > U-Boot SPL. > > > > Thanks! Then it looks like I'm closer to understanding then I initially > > thought. It gives a 405 since yesterday, but I have been studying > > https://opensource.rock-chips.com/wiki_Boot_option > > Yeah, I also got stuck with the vendor documentation and eventually just *had > a go* and eventually manged to get things working ;-). > > > > > To build U-Boot in Debian for these "new" targets we'd need to: > > > 1) build and distribute U-Boot for these "new" targets without the > > > TPL/TF-A > > > > AFAICT, TF-A for *rk356x* is really close to being mergeable? It appears to > > me > > that all that's needed is to "dot the i's" and the right people pushing the > > right 'buttons' (in the right sequence). > > AFAIC we can wait for that to happen. > > I'm not entirely sure about that. In any case, for the rk3588 in U-Boot > mainline we just boot > with vendor TPL & leave out TF-A entirely ;-). Maybe that could even be > possible with this board, > to just run without TF-A ? > > If you want to do that, see how we do it for rk3588 here: > https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/blob/rk3588-rock5b/.gitlab-ci.yml > I don't know if it will work for Quartz64, but please try it and see. My > fingers are crossed. Sorry, I was wrong. We set BL31 (which is TF-A from rkbin) and ROCKCHIP_TPL (which is TPL from rkbin) e.g: - export BL31=../rkbin/bin/rk35/rk3588_bl31_v1.27.elf - export ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin That was misleading. Apologies. > > The situation is different and therefor long(er) term when it comes to TF-A > > for > > rk3588 based devices. I'd like to see support for that in Debian > > 'eventually' > > too, but strictly speaking that's not the goal of this bug report. > > Right, see my comment above. Maybe we can just ignore TF-A on these devices > *for now* > until upstream is merged? That was wrong. I believe we can use TF-A from rkbin and combine things into an image later. > > > The tricky thing is TPL/DRAM training. > > Right, that is common between all of these "modern" devices, so I am really > trying to > not derail this into a rk3588 support thread, but that should be in a > separate bug report. > In theory, if we skip TF-A, the only thing we need is TPL from rkbin for both > boards. That was wrong. I believe we can use TF-A from rkbin and combine things into an image later. > > > > 2) package rkbin for Debian in non-free-firmware (I will happily do that) > > > > Thanks :-) > > AFAIUI the tricky part is about combining u-boot from 'main' (which Vagrant > > likes to keep in 'main' and I'm inclined to agree) with rkbin from non-free- > > firmware and *IF* that's allowed in 'main'. If not, what then? > > Create an u-boot-nff package, with (exact?) the same contents as u-boot, > > but > > just in a different archive area? So that it can then be combined to create > > an > > u-boot-rockchip-nff package (in n-f-f)? > > > > 3) have some scripts to collate the various bits into proper images (that > > > probably should go inside the image-building too
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
Hi Diederik, To stay on-topic here, I also have a Pine64 Quartz64 model A - I'd be happy to be added as a board maintainer in Debian. I didn't yet manage to build U-Boot mainline for it, see https://lists.denx.de/pipermail/u-boot/2023-August/526625.html I still owe a reply on that topic to Jonas' suggestions, I will hope to get to that next week. On Thu, 2023-08-31 at 17:50 +0200, Diederik de Haas wrote: > > Sorry, our mails collided and I didn't see your previous reply. > Ha! I thought about sending you a private mail about that, but chose not to > as > they weren't conflicting. No problem, on-list is probably best anyway so it is archived ;-) > > On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote: > > > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote: > > So far so good ;-). The only clarification I would like to make is the DDR > > init code is standalone, part of the TPL and is not anything to do with > > TF-A. It really is the first-stage boot code that runs after the maskrom. > > > > We could use Rockchip's closed implementation of that OR U-Boot's > > implementation, it's only real job is to train the DDR and handoff to > > U-Boot SPL. > > Thanks! Then it looks like I'm closer to understanding then I initially > thought. It gives a 405 since yesterday, but I have been studying > https://opensource.rock-chips.com/wiki_Boot_option Yeah, I also got stuck with the vendor documentation and eventually just *had a go* and eventually manged to get things working ;-). > > To build U-Boot in Debian for these "new" targets we'd need to: > > 1) build and distribute U-Boot for these "new" targets without the TPL/TF-A > > AFAICT, TF-A for *rk356x* is really close to being mergeable? It appears to > me > that all that's needed is to "dot the i's" and the right people pushing the > right 'buttons' (in the right sequence). > AFAIC we can wait for that to happen. I'm not entirely sure about that. In any case, for the rk3588 in U-Boot mainline we just boot with vendor TPL & leave out TF-A entirely ;-). Maybe that could even be possible with this board, to just run without TF-A ? If you want to do that, see how we do it for rk3588 here: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/blob/rk3588-rock5b/.gitlab-ci.yml I don't know if it will work for Quartz64, but please try it and see. My fingers are crossed. > The situation is different and therefor long(er) term when it comes to TF-A > for > rk3588 based devices. I'd like to see support for that in Debian 'eventually' > too, but strictly speaking that's not the goal of this bug report. Right, see my comment above. Maybe we can just ignore TF-A on these devices *for now* until upstream is merged? > The tricky thing is TPL/DRAM training. Right, that is common between all of these "modern" devices, so I am really trying to not derail this into a rk3588 support thread, but that should be in a separate bug report. In theory, if we skip TF-A, the only thing we need is TPL from rkbin for both boards. > > 2) package rkbin for Debian in non-free-firmware (I will happily do that) > > Thanks :-) > AFAIUI the tricky part is about combining u-boot from 'main' (which Vagrant > likes to keep in 'main' and I'm inclined to agree) with rkbin from non-free- > firmware and *IF* that's allowed in 'main'. If not, what then? > Create an u-boot-nff package, with (exact?) the same contents as u-boot, but > just in a different archive area? So that it can then be combined to create > an > u-boot-rockchip-nff package (in n-f-f)? > > 3) have some scripts to collate the various bits into proper images (that > > probably should go inside the image-building tool rather than in a Debian > > package like flash-kernel, since it will be hopefully obsolete one day :-)) > > My goal is to have all the parts *in* Debian as packages, so that I don't > need > to run a script to get/build u-boot for rk356x devices, but can just do > `apt-get install ` > > So the image-building is just used to build/'assemble' the image ;-) Let me rephrase myself. My suggestion is to ship in u-boot-rockchip U-Boot for these devices *without* any closed bits and ship rkbin in non-free-firmware in non-free-firmware. We need to simply combine those into an image file to flash to the device, that could be done in flash-kernel (or as my original suggestion in a script in the image building process but I am not fussy). So that script would "just" combine rkbin and the "open" parts of u-boot-rockchip into idbloader.img and u-boot.itb. And once the DDR init and AT-F bits are merged into mainline, we can remove those bits from flash-kernel and u-boot-rockchi
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
Hi Diederik, Sorry, our mails collided and I didn't see your previous reply. On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote: > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote: > > This is the case for some other devices (e.g. rk3588) currently where there > > is support in U-Boot mainline but there is no arm-trusted-firmware support > > _or_ DDR bringup in U-Boot as yet. > > I do follow the linux-rockchip ML and it looks like kernel 6.6 is getting > rather interesting for rk3588 support. > I'm less 'in the loop' wrt rk3588 on u-boot and TF-A although I did post this: > https://forum.pine64.org/showthread.php?tid=14432=117094#pid117094 There are a few open pull requests from Rockchip to add support but it is likely to take a while to be merged. > I do expect for TF-A support to land upstream for rk3588 (eventually), but do > you know (or suspect) that DRAM init will be open sourced too? I am not entirely sure of Rockchip's plans here. I have added Kever to the thread who can hopefully suggest when DRAM init code and TF-A support for various Rockchip processors will be submitted to mainline? > Note that I don't _fully_ understand these things, so if what I'm saying > doesn't make any sense, feel free to point that out :-) So far so good ;-). The only clarification I would like to make is the DDR init code is standalone, part of the TPL and is not anything to do with TF-A. It really is the first-stage boot code that runs after the maskrom. We could use Rockchip's closed implementation of that OR U-Boot's implementation, it's only real job is to train the DDR and handoff to U-Boot SPL. > > It'd be great to get Debian running on some of this more recent Rockchip > > hardware > > I'm currently working on that. Although it's initially for Quartz64 Model A+B > and PineTab2 (all rk3566) devices, I don't see why it wouldn't be usable for > rk3588 devices too as (long as) they're all arm64. > > AFAICT (now), I can just make 1 image as the only differentiator would be the > specific u-boot binary that needs to be put in place and I can just make an > instruction to `dd` the right u-boot binary onto sector 64 of the image file. > > Thus https://github.com/Kwiboo/u-boot-build/#flashing with `/dev/mmcblk0` > replaced by my image file. To build U-Boot in Debian for these "new" targets we'd need to: 1) build and distribute U-Boot for these "new" targets without the TPL/TF-A 2) package rkbin for Debian in non-free-firmware (I will happily do that) 3) have some scripts to collate the various bits into proper images (that probably should go inside the image-building tool rather than in a Debian package like flash-kernel, since it will be hopefully obsolete one day :-)) > > https://salsa.debian.org/diederik/linux/-/tree/pine64/master-next is the > kernel I (currently) use, which is based (and periodically rebased up) on the > Debian kernel (with the intend to 'upstream' it to Debian's kernel when > that's > appropriate). Great! I am interested in bringing up more of these boards in Debian too. I have some custom Debos recipes to build some images for these boards, but the recipes really aren't yet ready to go anywhere until we get kernel and bootloader sorted out. Thanks! Chris
Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices
Hi, On Wed, 2023-08-30 at 11:32 -0700, Vagrant Cascadian wrote: > On 2023-08-30, Diederik de Haas wrote: > > On Wednesday, 30 August 2023 16:35:46 CEST Vagrant Cascadian wrote: > > > > I also recall seeing references to a `rk3568_ddr_1056MHz_v1.18.bin` file > > > > from https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35. AFAIK > > > > that's only available as a BLOB? Is that file needed? And is it a > > > > problem > > > > if that's only available as a BLOB? > > > > > > If upstream u-boot requires that to work it is... more complicated. > > > > > > Looks like it does probably require it, based on the trustedfirmware > > > thread you linked to above. > > > > As mentioned above, AFAIK it's no different from rk3328/rk3399, but I'll > > ask. > > If the rk3568*.bin is not actually required to build an upstream > arm-trusted-firmware, then it is not different! > > If the rk3568*.bin is required to build an upstream > arm-trusted-firmware, then it is different! > > The current arm-trusted-firmware and u-boot packages for rk3328 and > rk3399 do not require those or other blobs. This is the case for some other devices (e.g. rk3588) currently where there is support in U-Boot mainline but there is no arm-trusted-firmware support _or_ DDR bringup in U-Boot as yet. There are two options I can see: 1) Workaround this by building the "open-source" part of U-Boot for these devices and letting users build their own final U-Boot binary with closed source parts. The licence now allows redistribution: https://github.com/rockchip-linux/rkbin/blob/master/LICENSE 2) Wait for arm-trusted-firmware and u-boot DDR bringup code to be open-sourced and merged into mainline. This could take some months to several years. If anyone is interested in option 1, I could be convinced to package rkbin in non-free-firmware/non-free possibly along with additional scripts to make things build... It'd be great to get Debian running on some of this more recent Rockchip hardware while we wait for Rockchip to sort out option 2. I've been told it's in progress ;-) Thanks! Chris
Bug#1041865: debos: Output of apt action not shown when running debos in noninteractive shell
Control: forwarded -1 https://github.com/go-debos/debos/issues/416 On Mon, 2023-07-24 at 17:56 +0200, q wrote: > Package: debos > Version: 1.1.1-2.1 > Severity: important > Tags: upstream > > Dear Maintainer, > > we're using debos within Gitlab CI runners which basically works. However the > output of apt does not appear in the job logs due to special character > sequences > printed by apt. This makes it hard to debug any issues if the apt action fails > and always requires us to run debos in an interactive shell manually. > > Please see https://github.com/go-debos/debos/issues/416 for details and Hi, It is shown, it is just that GitLab Runner seems to hide certain lines ending in certain newline character sequences. You _can_ get to the full apt actions logs by going to the job and pressing the "Show complete raw" button at the top next to the Search bar. > https://github.com/go-debos/debos/commit/b1197b80b4e87c6cd1cd7b06669faa7c40798551 > > for a possible solution which already has been merged into the upstream's main > branch. Would it be possible to include this patch in an package update? Unfortunately this will not fix the issue and the issue really belong to the GitLab runner and its termination character detection. I will search for an issue on the GitLab.com tracker, but so far I haven't found anything as yet. It would help if we could find a bug on the tracker already about the termination character issue.
Bug#1040542: dh-make should populate Multi-Arch field
Package: dh-make Version: 2.202301 Severity: wishlist Dear Maintainer, For most binary packages, setting Multi-Arch: foreign seems to be the best solution. dh-make should populate this field out-of-the-box such that this field doesn't get missed when creating new packages. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-make depends on: ii debhelper 13.11.4 ii dpkg-dev 1.21.22 ii make 4.3-4.1 ii python33.11.4-3 dh-make recommends no packages. Versions of packages dh-make suggests: ii build-essential 12.10 -- no debconf information
Bug#1040500: routine-update: Don't create d/salsa-ci.yml file
Package: routine-update Version: 0.1.1 Severity: normal Dear Maintainer, routine-update adds a file under the path "debian/salsa-ci.yml". According to the salsa-ci-team[1], the default recommendation is to set the pipeline URL in the project settings rather than to use a standaline debian/salsa-ci.yml file. Therefore, please remove the addition of this file and instead please print a warning if this file exists for manual intervention to change the pipeline to the recommended suggestion by the Salsa CI team. [1]: https://salsa.debian.org/salsa-ci-team/pipeline/#basic-use Cheers! Chris -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages routine-update depends on: ii cme1.038-1 ii devscripts 2.23.5 ii dpkg-dev 1.21.22 ii fakeroot 1.31-1.2 ii git1:2.40.1-1 ii git-buildpackage 0.9.30 ii gobject-introspection 1.74.0-3 ii libconfig-model-dpkg-perl 2.165 ii lintian-brush 0.149 ii pristine-tar 1.50 ii quilt 0.67+really0.66-1 routine-update recommends no packages. routine-update suggests no packages. -- no debconf information
Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork
Hi Jonas,
On Tue, 2023-07-04 at 17:06 +0200, Jonas Smedegaard wrote:
> Hi Cristopher,
>
> Quoting Christopher Obbard (2023-07-04 16:01:19)
> > On Sat, 2023-07-01 at 11:07 +0200, Jonas Smedegaard wrote:
> > > I own a PineNote, and use rkdeveloptool for flashing software onto it,
> > > but have found the code in Debian to be inferior for that use.
> > >
> > > Please consider switching to the (slightly) newer fork done by Pine64,
> > > which fixes some bugs and improves the user interface, while seemingly
> > > fully preserving backwards compatibility:
> > > https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool
> > >
> > > What I use now is a fork of this package, maintained here:
> > > https://salsa.debian.org/js/rkdeveloptool
> > >
> > > If you like, I can push that into the official Salsa packaging git -
> > > or you can cherry-pick the bits you like from it, of course. :-)
> >
> > I'm fine with picking your patches to the packaging and changing the
> > upstream source to this (backwards-compatible) version & uploading a new
> > version.
> >
> > One question is what do we do about the version? Currently we are tracking
> > the upstream source from rockchip
> > https://github.com/rockchip-linux/rkdeveloptool which
> > is at version 1.32+git20210408.46bb4c0 but the Pine64 version is at
> > currently tagged at
> > version 1.1.0 which is much lower. I wonder if I should do something like
> > tag the new
> > upstream source version with an epoch, like 2:1.1.0 ?
> >
> > The policy states that prepending an epoch to a pacakge version needs some
> > additional consensus from debian-devel:
> > > You should not change the epoch, even in experimental, without getting
> > > consensus on debian-devel first.
> >
> > so I have therefore CC the list to this bug, to see if my thinking is
> > correct :-)
>
> Since none of these forks apparently is actively developed, I suggest to
> not take any strong action like introducing an epoch, but instead simply
> add a + to indicate that current situation is a mess - which it is:
>
> 1.32+pine64.20210904
Right, I have done this and pushed my (unreleased) changes to
https://salsa.debian.org/debian/rkdeveloptool/-/commits/wip%2Fobbardc%2Fpine64
Lintian complains about the following in my unstable pbuilder:
E: rkdeveloptool: non-standard-toplevel-dir [rules.d/]
W: rkdeveloptool: file-in-unusual-dir [rules.d/99-rk-rockusb.rules]
I think it is because in meson.build udev.get_pkgconfig_variable is returning
false for udevdir, and the
udev rules aren't being installed into the correct location.
udev_rules_dir = udev.get_pkgconfig_variable('udevdir') + '/rules.d'
Did you have this issue? Do you have any hints, maybe you could add a fix into
your patches file?
> Also, I do not recommend to include a git hash, because that is not
> sortable like a date is. If you ever need to release twice on same day
> then simply add a .1 suffix.
I think the git hash is quite nice as it shows where the upstream source
actually
came from. This seems to be a standard all around Debian, is there any official
notes/guidance you can point me to or is this mainly down to developer choice?
In any case, for this package, I doubt that upstream will release twice on the
same
day, given that there hasn't been much movement since 2021 ;-). I will be
careful to
make sure I consider this in future.
>
> > Note that also we have written a replacement tool in Rust called rockusb
> > (which allows you to write an image with holes to the device, which can
> > speed up the flashing), packaging this in Debian is also on my the wishlist:
> > https://github.com/collabora/rockchiprs/tree/main
>
> Ohh, that looks very nice!
>
> D you prefer to package that yourself? I am on a
> package-cool-rust-stuff frenzy and can offer to do the packaging of that
> tool if you like. Then we can maintain it together, but easiest for me
> is that I simply do the bootstrapping myself.
I would love to do more Rust packaging in Debian, but I really am out of time
to do that work currently. I looked at the dependency tree and it seems like
it would be a number of packages.
I am able to help maintain the additional package(s).
Would you be able to start another email thread about that (possibly in a new
WNPP bug?) to not pollute this bug.
Thanks!
Chris
Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork
Hi Jonas, On Sat, 2023-07-01 at 11:07 +0200, Jonas Smedegaard wrote: > Package: rkdeveloptool > Version: 1.32+git20210408.46bb4c0-3 > Severity: wishlist > Tags: upstream > > I own a PineNote, and use rkdeveloptool for flashing software onto it, > but have found the code in Debian to be inferior for that use. > > Please consider switching to the (slightly) newer fork done by Pine64, > which fixes some bugs and improves the user interface, while seemingly > fully preserving backwards compatibility: > https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool > > What I use now is a fork of this package, maintained here: > https://salsa.debian.org/js/rkdeveloptool > > If you like, I can push that into the official Salsa packaging git - > or you can cherry-pick the bits you like from it, of course. :-) I'm fine with picking your patches to the packaging and changing the upstream source to this (backwards-compatible) version & uploading a new version. One question is what do we do about the version? Currently we are tracking the upstream source from rockchip https://github.com/rockchip-linux/rkdeveloptool which is at version 1.32+git20210408.46bb4c0 but the Pine64 version is at currently tagged at version 1.1.0 which is much lower. I wonder if I should do something like tag the new upstream source version with an epoch, like 2:1.1.0 ? The policy states that prepending an epoch to a pacakge version needs some additional consensus from debian-devel: > You should not change the epoch, even in experimental, without getting > consensus on debian-devel first. so I have therefore CC the list to this bug, to see if my thinking is correct :-) Note that also we have written a replacement tool in Rust called rockusb (which allows you to write an image with holes to the device, which can speed up the flashing), packaging this in Debian is also on my the wishlist: https://github.com/collabora/rockchiprs/tree/main Cheers! Chris
Bug#1035436: rkdeveloptool: diff for NMU version 1.32+git20210408.46bb4c0-2.1
Hi Andreas, I uploaded a new version this morning with the fix; it has a -3 suffix so it should reject your NMU which had a -2.1 suffix. As I am fairly new to Debian processes, it is great you have walked me through it. Thank you! On 20 May 2023 12:07:03 BST, Andreas Metzler wrote: >On 2023-05-20 Christopher Obbard wrote: >[...] >> > I've prepared an NMU for rkdeveloptool (versioned as >> > 1.32+git20210408.46bb4c0-2.1) and uploaded it to DELAYED/1. >[...] >> Thank you for your contribution, but it seems like there is some >> parallel work (this morning in fact). > >> I am currently in the process of uploading and the fixes for this >> package. Is it possible to skip this delayed version in favour of the >> version I am about to upload ? > >Hello Christopher, > >if you upload before the NMU is accepted the NMU will simply be >rejected because there is already a higher numbered version of the >package in the archive. I can also simply cancel the NMU or bump the >delay if you want me to. - Just tell me what your preference is. > >cu Andreas >-- >`What a good friend you are to him, Dr. Maturin. His other friends are >so grateful to you.' >`I sew his ears on from time to time, sure'
Bug#1035436: rkdeveloptool: diff for NMU version 1.32+git20210408.46bb4c0-2.1
Hi, On Sat, 2023-05-20 at 11:07 +0200, Andreas Metzler wrote: > Control: tags 1035436 + patch > Control: tags 1035436 + pending > > Dear maintainer, > > I've prepared an NMU for rkdeveloptool (versioned as > 1.32+git20210408.46bb4c0-2.1) and uploaded it to DELAYED/1. Please feel > free to tell me if I should delay it longer. Thank you for your contribution, but it seems like there is some parallel work (this morning in fact). I am currently in the process of uploading and the fixes for this package. Is it possible to skip this delayed version in favour of the version I am about to upload ? > > kind regards > > Andreas
Bug#1025956: u-boot-menu: Allow automatic sync of DTBs when /boot is a separate partition
Hi Arnaud, [ +cc Vagrant who seems to care about u-boot-menu. ] On Mon, 12 Dec 2022 15:16:45 +0100 Arnaud Ferraris wrote: > Source: u-boot-menu > Version: 4.2.0 > Severity: wishlist > Tags: patch > X-Debbugs-Cc: aferra...@debian.org > > Dear Maintainer, > > It is common practice for /boot to be on a separate partition, requiring DTBs > to be synced to this partition for u-boot to be able to access them. > > This used to be done manually, or required additional scripts to be installed > by the user for automatic processing. As I think it would be useful for > u-boot- > menu to automatically perform such synchronization, I have implemented such a > feature and attached the corresponding patches. > > Please note this feature is currently guarded by a new config option, as I > expect users might get surprised and/or unexpected results by a sudden > behaviour change that important. > > Comments and suggestions are obviously welcome. Ack from me on these patches. I think this patch series is the final part in letting u-boot-menu handle systems where a separate /boot partition is useful. I'd even suggest to enable this by default on systems where there is a separate /boot partition. Thank you! Christopher Obbard
Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1
Hi Andreas, On Thu, 2023-04-06 at 18:45 +0200, Andreas Henriksson wrote: > Hello Chris, > > On Thu, Apr 06, 2023 at 04:37:30PM +0100, Christopher Obbard wrote: > > Hi Andreas, > > > > As the upstream maintainer, I can just tag a new version upstream as 1.1.2 > > & pick that in Debian. > > Then I hope it can flow into bookworm? > > I wonder if the release team will accept a new upstream release at this > point in the freeze We're pretty deep into the hard freeze at this > point (but I don't have enough insight into how the release team works > these days, it seems much more relaxed than in the old times where I was > more involved and basically any extra character would get you a NACK, > specially an "unneccessary" upstream version number change). > > Do you have time to do all the work and still accept a potential NO from > the release team? Please be honest to yourself. > > IMHO it feels much safer to just go with a targeted upload (which is now > also already approved), but if you feel strongly about it and also think > you have time to pursue a new release then just send me a NACK on the > NMU (ASAP! I'm ready to upload *now*) and I will not pursue it. Let's go with your NMU, since you've done all of the work already, then I will upload the new version into unstable once development opens. How does that sound? PS: Can you push your source to salsa? Thanks! Chris > > > > > The past few months have been... quite crazy in my personal life so I > > haven't gotten around to doing this as yet. Huge apologies for that, > > it is on my radar this week. > > > > Hope that is acceptable to you? > > No need to apologize. We're all busy sometimes and that's why we have > NMUs so we can help each other out. (I've also been quite busy or the > NMU would have happened much sooner in the release cycle.) > Thanks for all the work you have had time to do! > > > > > Thanks, > > > > Chris > > Regards, > Andreas Henriksson > > PS. Feel free to ignore my NMU and just upload the new upstream release > once we're past the freeze/release and the development opens up again.
Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1
Hi Andreas, As the upstream maintainer, I can just tag a new version upstream as 1.1.2 & pick that in Debian. Then I hope it can flow into bookworm? The past few months have been... quite crazy in my personal life so I haven't gotten around to doing this as yet. Huge apologies for that, it is on my radar this week. Hope that is acceptable to you? Thanks, Chris On Thu, 2023-04-06 at 15:51 +0200, Andreas Henriksson wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: de...@packages.debian.org > Control: affects -1 + src:debos > > > Hello release-team, > > I'm looking for a pre-approval for an unblock of my NMU of debos, > which contains 3 commits cherry-picked from upstream. > > The main bug to fix is https://bugs.debian.org/1027787 > The current version of debos in bookworm is not compatible with > bookworm. The maintainer promised me to deal with this if I > submitted an upstream PR where he merged my patch for it, > but apparently never found the time to update the debian > package. > > While at it I also cherry-picked 2 documentation fixes. > > I'm attaching a debdiff, but if you'd like to avoid reading > patch-in-patch these are the commits: > https://github.com/go-debos/debos/commit/18998ffaf78321e111d9823b3180eca3fa4593f6 > https://github.com/go-debos/debos/commit/f4ff78305513a90eca089e33f7bba35bffa96bd1 > https://github.com/go-debos/debos/commit/c8c5075853aab9e1ac6ae07a3a7c2b070aa38a62 > > > unblock debos/1.1.1-2.1
Bug#1031640: Info received (Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize)
Control: retitle -1 e2fsprogs generates filesystems which cannot be mounted on systems with older e2fsprogs
Bug#1031640: Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize
Control: severity -1 important Control: retitle -1 e2fsprogs generates filesystems which cannot be mounted on systems with older e2fsprogs It turns out for debos the situation is a bit different. Since debos uses packages on the host to prepare the partitions, new features in e2fsprogs from unstable which are unsupported in the target suite causes the built system to not boot. One such failure at boot-time of a Debian testing system is when systemd-fsck tries to check a filesystem, it fails to mount the device: /dev/mmcblk0p5 has unsupported feature(s): FEATURE_C12 So, in short we cannot run images built for suites with older e2fsprogs on a host system which has e2fsprogs >=1.47.0-1. Fixing grub2 will not fix the issue for debos, so I have retitled the bug. In debos with newer e2fsprogs, we can set the following flag on a partition to disable the feature which allows the system running older e2fsprogs to boot, but older e2fsprogs doesn't allow us to set this flag: features: [ "^orphan_file" ] So to my mind, the bug is in e2fsprogs as it doesn't maintain backwards compatibility. I have reduced the severity of the bug since a workaround for debos does exist. I wonder whether the bug should be reassigned to e2fsprogs ?
Bug#1016963: Please test u-boot for rock-pi-4-rk3399
On Thu, 2023-01-05 at 13:21 -0300, Walter Lozano wrote: > Hi Christopher and Vagrant > > On 1/5/23 12:10, Christopher Obbard wrote: > > On Wed, 2022-12-28 at 15:53 -0800, Vagrant Cascadian wrote: > > > On 2022-12-28, Vagrant Cascadian wrote: > > > > On 2022-12-22, Vagrant Cascadian wrote: > > > > > On 2022-08-20, Vagrant Cascadian wrote: > > > > > > On 2022-08-10, Vagrant Cascadian wrote: > > > > > > > This bug is just to delay migration to testing while more > > > > > > > platforms get > > > > > > > tested. If you have a relevent board, please consider > > > > > > > testing > > > > > > > and > > > > > > > reporting the status: > > > > > > > > > > > > > > https://wiki.debian.org/U-boot/Status > > > > > > > > I have not received many test results for current or even > > > > remotely > > > > recent u-boot platforms in Debian, and u-boot has been blocked > > > > from > > > > migration to testing partly because of this. > > > > > > > > As the bookworm freeze approaches, this is getting to be... > > > > worrysome! > > > > > > > > If you have access to any of these boards, please consider > > > > testing > > > > u-boot versions as packaged in debian for versions from debian > > > > stable > > > > (2021.01*), testing (2022.04*), unstable (2022.10*) and > > > > experimental > > > > (2023.01-rc*) and updating the wiki page if successful and/or > > > > replying > > > > to 1016...@bugs.debian.org with a positive confirmation... > > > > > > > > ...and if not successful, filing bugs against the relevent u- > > > > boot-* > > > > packages and marking them as blocking 1016963. > > > > > > rock-pi-4-rk3399 > > > > Hi Walter, Hi Vagrant, > > > > > > I tested this board and updated the wiki. All looks fine to me. > > > > - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from > > experimental > > - SD boot: works > > - MAC address: correctly derived from serial number > > > > > > - rock-pi-4-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable > > - SD boot: works > > - MAC address: correctly derived from serial number > > > > Thank you for your help here! I also did some testing, and everything > looks OK. The only thing to mention is that the the script > u-boot-install-rockchip does not auto detect my board. > > The case statement is > ``` > "Radxa ROCK Pi 4") > TARGET="/usr/lib/u-boot/rock-pi-4-rk3399" > ``` Ah, good catch! For compatiblity with mainline (debian) kernel, that line should probably be updated to: "Radxa ROCK Pi 4A"|"Radxa ROCK Pi 4A+"|"Radxa ROCK Pi 4B"|"Radxa ROCK Pi 4B+") The Radxa kernel[1] 4.14 branches use "ROCK PI 4A" and "ROCK PI 4B", we could add those in if we really wanted to. The 5.10 based kernels use devicetrees based on mainline, so are unaffected. Thanks! Chris [1]: https://github.com/radxa/kernel/blob/stable-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts > > fails since the string in my case is only "ROCK Pi 4". Of course, by > setting TARGET variable I can upgrade it without problems. I don't > consider this an issue and it is probably related to the kernel I am > using, since I have used as starting point the images from Radxa [1]. > > Regards, > > Walter > > [1] https://wiki.radxa.com/Rockpi4/downloads >
Bug#1027787: debos: Unusable with recipes using bookworm suite (or newer)
Hi Andreas, On Thu, 2023-01-05 at 00:31 +0100, Andreas Henriksson wrote: > Control: tags -1 + upstream > Control: forwarded -1 https://github.com/go-debos/debos/pull/390 > > Hello, > > On Tue, Jan 03, 2023 at 11:34:27AM +0100, Andreas Henriksson wrote: > > Package: debos > > Version: 1.1.1-2 > > Severity: important > > > > Dear Maintainer, > > > > Using debos to build a recipe that uses bookworm or newer suite > > gives a mysterious apt error that suggest running apt --fix-broken > > install. > > > > This is a symptom of the workaround that was applied for > > https://github.com/go-debos/debos/issues/361 > > "New debootstrap is unable to bootstrap pre-bookworm debian > > derivatives" > [...] > > For the record, this first problem was handled upstream at > https://github.com/go-debos/debos/pull/390 > > [...] > > 2023/01/03 01:19:51 apt | Setting up linux-image-6.0.0-6-arm64 > > (6.0.12-1) ... > > 2023/01/03 01:19:55 apt | I: /vmlinuz.old is now a symlink to > > boot/vmlinuz-6.0.0-6-arm64 > > 2023/01/03 01:19:55 apt | I: /initrd.img.old is now a symlink to > > boot/initrd.img-6.0.0-6-arm64 > > 2023/01/03 01:19:55 apt | I: /vmlinuz is now a symlink to > > boot/vmlinuz-6.0.0-6-arm64 > > 2023/01/03 01:19:55 apt | I: /initrd.img is now a symlink to > > boot/initrd.img-6.0.0-6-arm64 > > 2023/01/03 01:19:56 apt | /etc/kernel/postinst.d/initramfs-tools: > > 2023/01/03 01:19:56 apt | update-initramfs: Generating > > /boot/initrd.img-6.0.0-6-arm64 > > 2023/01/03 01:19:56 apt | W: No zstd in /usr/bin:/sbin:/bin, using > > gzip > > 2023/01/03 01:30:32 apt | Container root terminated by signal KILL. > > Powering off. > > open /tmp/fakemachine-194296958/result: no such file or directory > > This second problem turned out to be because the default 2Gb memory > setting for fakemachine/qemu is apparently no longer enough to run > update-initramfs against the bookworm arm64 kernel modules in > linux-image-arm64. > > Using `debos --memory=4Gb ...` resolved this issue for me. >From previous mails I take it you're building https://github.com/go-debos/debos-recipes/blob/main/rpi64/debimage-rpi64.yaml#L50 with suite set to bookworm ? Ideally we'd like to keep to 2gb by default since we try to use cloud runners with small RAM to keep costs down. By default debos creates a tmpfs to store the temporary rootfs. Once the filesystem has been deployed to the image, Debos works on the image (stored on disk) directly rather than a tmpfs. Perhaps you could open an issue upstream to discuss changing the default memory to 4gb ? I think the problem with that sample recipe is that it installs the kernel (thus building the initramfs) _before_ it has been deployed to an image using filesystem-deploy. To fix this recipe, you should instead move the kernel install to after the filesystem-deploy action. I'd happily accept a PR for that. Also, those recipes are quite outdated and unmaintained so please take them with a pinch of salt. Thanks, Chris > > Maybe it would be useful to consider bumping the default memory > setting? > > Regards, > Andreas Henriksson >
Bug#1016963: Please test u-boot for rock-pi-4-rk3399
On Wed, 2022-12-28 at 15:53 -0800, Vagrant Cascadian wrote: > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > > > On 2022-08-20, Vagrant Cascadian wrote: > > > > On 2022-08-10, Vagrant Cascadian wrote: > > > > > This bug is just to delay migration to testing while more > > > > > platforms get > > > > > tested. If you have a relevent board, please consider testing > > > > > and > > > > > reporting the status: > > > > > > > > > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... > > worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian > > stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and > > experimental > > (2023.01-rc*) and updating the wiki page if successful and/or > > replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > rock-pi-4-rk3399 Hi Walter, Hi Vagrant, I tested this board and updated the wiki. All looks fine to me. - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number
Bug#1016963: please test u-boot for roc-pc-rk3399 rock-pi-e-rk3328
Hi Vagrant, On Wed, 2022-12-28 at 15:51 -0800, Vagrant Cascadian wrote: > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > > > On 2022-08-20, Vagrant Cascadian wrote: > > > > On 2022-08-10, Vagrant Cascadian wrote: > > > > > This bug is just to delay migration to testing while more > > > > > platforms get > > > > > tested. If you have a relevent board, please consider testing > > > > > and > > > > > reporting the status: > > > > > > > > > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... > > worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian > > stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and > > experimental > > (2023.01-rc*) and updating the wiki page if successful and/or > > replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > roc-pc-rk3399 > rock-pi-e-rk3328 Sorry for the delay, I've been catching up after the Christmas break ;- ) I've tested the following platforms and updated the wiki with my results: - roc-pc-rk3399, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - roc-pc-rk3399, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: random on each boot, patch needs backporting from experimental - rock-pi-e-rk3328, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-e-rk3328, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4b-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number @Vagrant, about roc-pc-rk3399, can you please backport debian/patches/rockchip/rockchip-roc-pc-rk3399-Enable-rockchip-efuse- support.patch to the next unstable release ? If you prefer, I could create another bug about that. Thanks! Chris
Bug#1027787: debos: Unusable with recipes using bookworm suite (or newer)
debos depends on: > ii busybox-static [busybox] 1:1.35.0-4+b1 > ii debootstrap 1.0.128+nmu2 > ii libc6 2.36-7 > ii libglib2.0-0 2.74.4-1 > ii libostree-1-1 2022.7-2 > ii qemu-system-x86 1:7.2+dfsg-1+b2 > ii qemu-user-static 1:7.2+dfsg-1+b2 > ii systemd-container 252.4-1 > > Versions of packages debos recommends: > ii bmap-tools 3.6-1 > ii bzip2 1.0.8-5+b1 > ii e2fsprogs 1.46.6~rc1-1+b1 > ii linux-image-amd64 6.0.12-1 > ii mount 2.38.1-4 > ii ovmf 2022.11-2 > ii parted 3.5-3 > ii systemd-resolved 252.4-1 > ii udev 252.4-1 > ii xz-utils 5.4.0-0.1 > ii zip 3.0-12 > > Versions of packages debos suggests: > pn libslirp-helper > pn user-mode-linux > > -- no debconf information -- Christopher Obbard BEng (Hons) MIET Senior Engineer Collabora Ltd Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK Registered in England & Wales no 5513718.
Bug#1026080: archlinux-keyring: Please backport latest version to bullseye-backports
Source: archlinux-keyring Version: 0~20220831-1~bpo11+1 Severity: minor Dear Maintainer, Please backport archlinux-keyring to bullseye-backports. The version available in bullseye-backports is too outdated to be able to generate an Arch rootfs using arch-install-scripts from bullseye-backports. Thank you. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1013227: Jack dependency
Hi! Please try the qpwgraph package for all of your pipewire graph needs. Best, Chris On 16 November 2022 20:58:41 CET, Gonsolo wrote: >I'm running the ardour on Kinetic and qjackctl with pipewire-jack runs >flawlessly. >I learned about qpwgraph here and I'm happily using it. > >But: > >I had to run "pw-jack qjackctl" because jack2 was installed, and jack2 was >installed because of qjackctl. >If it is a build dependency it should be just this, a build-dependency. >The dependency then should be (jack2 | pipewire-jack). > >Also, I didn't check but it should be possible to build qjackctl with the >headers from pipewire-jack so even the build-dependency could be changed. > >I consider this a bug because without jack2 on the system I would not have >to run qjackctl through pw-jack. > >Best regards, >g
Bug#1020690: fakemachine should depend on systemd-resolved
On Fri, 2022-11-04 at 01:34 +0100, Diederik de Haas wrote: > On 25 Sep 2022 Christopher Obbard wrote: > > Package: fakemachine > > Version: 0.0~git20210901.fc48786-1+b2 > > Severity: important > > > > The latest systemd packages do not include systemd-resolved; it was > > split > > out into a seperate package. > > > > Because of this, on a machine which does not have systemd-resolved > > installed, fakemachine no longer works as intended. > > Due to https://salsa.debian.org/raspi-team/image-specs/-/issues/64 I > installed > `fakemachine`, but without systemd-resolved and I got the same build > failure: > E: Failed getting release file > http://deb.debian.org/debian/dists/bookworm/Release > > I have no idea why, as it works with any other program. > > I didn't install systemd-resolved as I have resolvconf installed and > installing > systemd-resolved would remove resolvconf. > > I don't get why it would need that exact program for network > connectivity. > I found https://github.com/go-debos/fakemachine/pull/115 and ofc this > bug, > where the problem seems to be directed at the packaging (i.e. not > hard-depending on systemd-resolved), while it seems a problem with > the program > itself (fakemachine). > > FWIW: version is 0.0.3-3 on Debian Sid Hi Diederik, I opened https://github.com/go-debos/fakemachine/issues/123 upstream to try to capture this bug. Thanks, Chris
Bug#1023386: pacman-package-manager: Please backport to bullseye-backports
Source: pacman-package-manager Version: 6.0.2-1 Severity: wishlist Dear Maintainer, In debos (https://github.com/go-debos/debos) we are enabling support for building Arch images. As part of Debos upstream, we ship a container based on Debian Bullseye which should support all of the features available in Debos. We need pacman to install packages inside the built image, which is only available for >bookworm. Since it's not feasible to upgrade our container images to bookworm as it's still testing, would it be possible to backport pacman-package-manager to bullseye-backports? >From a first look, it seems that it _should_ be simple enough if the package is compatible with libssl-dev 1.1.1n (there is no version requirement in meson.build), the other build-deps are already available in bullseye. Thank you for your consideration. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1006823: debos example has adduser waiting for password
Hi Geert, On Sat, 5 Mar 2022 21:47:37 +0100 Geert Stappers wrote: > Package: debos > Version: 1.0.0+git20210707.c66a48d-2 > Severity: minor > > Hello debos maintainers, > > > Doing > > debos /usr/share/doc/debos/examples/example.yaml > > got me a waiting / hanging debos. > > But the provide example should just work ... Since this is an upstream bug, I opened https://github.com/go-debos/debos/pull/375 to both modernise the example and also fix this bug... I plan for it to be in the next debos upstream release. Thanks! Chris
Bug#1020691: debos should depend on systemd-resolved
On Tue, 2022-10-25 at 07:47 +0700, Arnaud Rebillout wrote: > On 24/10/2022 21:55, Christopher Obbard wrote: > > I'm more leaning on just adding it as a direct Dependency to the > > Debos > > package and seeing if anyone moans... > Works for me. Seems installing systemd-resolved breaks the autopkgtest test runner, at least in a local qemu instance :-). For now I will leave it as a Recommends.
Bug#1020691: debos should depend on systemd-resolved
On Mon, 2022-10-24 at 20:00 +0700, Arnaud Rebillout wrote: > > On 24/10/2022 17:34, Christopher Obbard wrote: > > > I have proposed[1] to check if systemd-resolved is available at > > runtime, to at least let users know *why* name resolution doesn't > > work > > inside their fakemachine over letting the user debugging it > > themselves. > > > [1]: https://github.com/go-debos/fakemachine/pull/115 > That's nice! I thought of it as well, and I was wondering if systemd- > resolved (and possibly other services) should be listed under > Requires= instead of Wants= (talking about > https://github.com/go-debos/fakemachine/blob/main/machine.go#L288). > But then, I noticed commit 4c60b85a8302f0fa544adae73f0649726034711c, > and why using Wants= is the intention. So your approach works better. That's been merged into Fakemachine now. > > Perhaps we should add systemd-resolved to Suggests in > > debos/fakemachine? Adding it as a Depends/Recommends would break > > users > > who have some other package on their machine handling name > > resolution. > > > > @Arnaud, how does that sound? > Well, I'm not sure for the packaging part. If fakemachine needs > systemd-resolved to be functional, then it should be a Depends. > That's what Depends is for. > At a quick glance, there's no reverse dependencies of fakemachine / > debos. So the only users that would be surprised by the change are > the ones who installed it explicitly, so we can assume those are > technical users and they'll find their way? But then, what if there > are some installations on servers (think builders), and the upgrade > breaks the name resolution? Not a nice surprise. > OTOH, an error message saying that "/lib/systemd/systemd-resolved is > missing", plus a Suggests: systemd-resolved, both together gives a > strong hint regarding what should be done. It sounds sensible as > well. > Sorry, that's not really a clear answer :) > Best, I'm more leaning on just adding it as a direct Dependency to the Debos package and seeing if anyone moans...
Bug#989145: Please do not use uml fakemachine backend in the DEP-8 test
On Mon, 2022-10-24 at 07:38 -0300, Lucas Kanashiro wrote: > Hi Chris, > > On 24/10/2022 06:32, Christopher Obbard wrote: > > Hi Lucas & Steve, > > > > On Wed, 25 May 2022 17:25:29 -0300 Lucas Kanashiro > > wrote: > > > On Wed, 29 Sep 2021 15:21:01 -0700 Steve Langasek > > > wrote: > > > > My current suggestion is: > > > > - ask for an additional autopkgtest in Debian that runs with > > > > debos > > > > --disable-fakemachine (instead of replacing the current > > autopkgtest) > > > > - introduce an Ubuntu delta that drops the autopkgtest which > > depends on > > > > fakemachine > > > > - optionally, patch debos in Ubuntu to use --disable- > > > > fakemachine by > > > default? > > > > > > Since we got no reply so far I patched debos to use > > > --disable-fakemachine and adjusted the test dependencies and > > > restrictions in Ubuntu. > > > > > > Hopefully, we'll sort this out in Debian and then we can drop the > > delta > > > added. > > I plan on implementing the following when releasing a new version: > > > > 1) modify the build-chroot autopkgtest to use --disable-fakemachine > > in > > the debos call and remove the additional dependencies (e.g. just > > running on the host, this will need Restrictions: needs-sudo) > > I think you meant "needs-root" restriction here, right? Well, either works for me, but typically a user who is using debos with --disable-fakemachine will use sudo to elevate privileges rather than running as the root account. This will make the test better reflect reality. Does it make sense to use needs-sudo in this case? > > > 2) add an additional autopkgtest, build-chroot-uml to build a > > chroot > > using the uml backend, but with Restrictions: skip-not-installable > > so > > to not fail if user-mode-linux is not available in downstreams? > > This is a possible solution, it should work fine. > > > Would this be suitable or do you have other suggestions which would > > allow downstreams to test debos without downstream patches :-) > I believe with that we will be able to make is a sync from Debian > again > in Ubuntu. Thanks for working on it. >
Bug#1020691: debos should depend on systemd-resolved
On Thu, 2022-10-06 at 10:11 +0700, Arnaud Rebillout wrote: > > On 05/10/2022 22:06, Michael Biebl wrote: > > I think if you want to assemble a root/usr fs where you don't want > > do > > "disturb" the host system, I'd use a debootstrapped chroot but not > > the > > host fs. > > I think the original reason for fakemachine to exist was to build OS > images from within containers. At first it doesn't sound like a great > idea, because usually there's not enough capabilities in the > container > for that (ie. no access to the loop device). But systems like Jenkins > or > GitLab CI drop you in a container, you have no choice. So fakemachine > came as a solution / workaround to spawn a VM from within a container > (according that you have access to /dev/kvm), and then from within > the > VM you can build an OS image. > > Hence this weird approach of "faking a machine", ie. creating a VM by > reusing bits from the host filesystem. To say it again: if you're > already within an environment that has been setup for the job (chroot > or > container), no need to debootstrap a chroot again, let's just make > sure > this environment has everything needed, and re-use it for the VM. > That's > the approach of fakemachine, as I understand it. > > And so, for this use-case when fakemachine is used from within a > chroot/container, I must say that the systemd-resolved split is not > really problematic: all it takes is to add systemd-resolved to the > list > of packages to install in the chroot/container. > > The issue is for people installing fakemachine on their own machine. > So > far it worked great (I've been using it a lot to build OS images). > Now > it doesn't anymore. So either I install systemd-resolved, either I > start > a chroot and run fakemachine from there. It doesn't work "out of the > box" anymore, if you want. > > > > Say you want to install apache2 in your fakemachine managed VM, > > this > > would also start it on the host system, or not? > > Yes, but this comparison is not really relevant here. systemd- > resolved > is needed for the VM to have a functional network, so it's really a > prerequisite for a functional VM, regardless of what users want to do > with it. Hence the question of whether it should become a Depends for > the fakemachine package. > > While apache2 will never be a Depend of fakemachine in any case, and > if > users have a need for a particular need for that, it's in their hand > to > decide how to do it. > > Maybe fakemachine is more or less a VM counterpart of "systemd-nspawn > -D > / -xb" (systemd-nspawn(1), example 6)? > > I hope that I clarified a few points here. Would be nice to hear more > from fakemachine maintainers. > > Best regards, > I have proposed[1] to check if systemd-resolved is available at runtime, to at least let users know *why* name resolution doesn't work inside their fakemachine over letting the user debugging it themselves. Perhaps we should add systemd-resolved to Suggests in debos/fakemachine? Adding it as a Depends/Recommends would break users who have some other package on their machine handling name resolution. @Arnaud, how does that sound? [1]: https://github.com/go-debos/fakemachine/pull/115
Bug#989145: Please do not use uml fakemachine backend in the DEP-8 test
Hi Lucas & Steve, On Wed, 25 May 2022 17:25:29 -0300 Lucas Kanashiro wrote: > On Wed, 29 Sep 2021 15:21:01 -0700 Steve Langasek > wrote: > > > > My current suggestion is: > > - ask for an additional autopkgtest in Debian that runs with debos > > --disable-fakemachine (instead of replacing the current autopkgtest) > > - introduce an Ubuntu delta that drops the autopkgtest which depends on > > fakemachine > > - optionally, patch debos in Ubuntu to use --disable-fakemachine by > default? > > Since we got no reply so far I patched debos to use > --disable-fakemachine and adjusted the test dependencies and > restrictions in Ubuntu. > > Hopefully, we'll sort this out in Debian and then we can drop the delta > added. I plan on implementing the following when releasing a new version: 1) modify the build-chroot autopkgtest to use --disable-fakemachine in the debos call and remove the additional dependencies (e.g. just running on the host, this will need Restrictions: needs-sudo) 2) add an additional autopkgtest, build-chroot-uml to build a chroot using the uml backend, but with Restrictions: skip-not-installable so to not fail if user-mode-linux is not available in downstreams? Would this be suitable or do you have other suggestions which would allow downstreams to test debos without downstream patches :-) Thanks! Chris
Bug#1022058: spirv-headers: Please upgrade to spirv-headers >=1.3.224
Package: spirv-headers Version: 1.6.1+1.3.216.0-1 Severity: normal Dear Maintainer, mesa 22.3 in debian-experimental FTBFS with the following tests failing: Failed Tests (4): LLVM_SPIRV :: transcoding/AtomicFMaxEXT.ll LLVM_SPIRV :: transcoding/AtomicFMaxEXTForOCL.ll LLVM_SPIRV :: transcoding/AtomicFMinEXT.ll LLVM_SPIRV :: transcoding/AtomicFMinEXTForOCL.ll Turns out we need to bump spirv-headers to >= 1.3.224 and make sure llvm-spirv-translator gets built against that.
Bug#1021711: rustc: Bootstrapping process only seems to work for amd64
Package: rustc Version: 1.61.0+dfsg1-2 Severity: normal Dear Maintainer, When following the bootstrapping process in d/README.source, it only seems to generate a tarball with the amd64 binaries despite the variable upstream_bootstrap_arch set to include more bootstrap architectures. I am running: $ upstream_bootstrap_arch="amd64 arm64" debian/rules source_orig-stage0 ... debian/make_orig-stage0_tarball.sh downloading https://static.rust-lang.org/dist/2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz 100.0% extracting rustc/build/cache/2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz downloading https://static.rust-lang.org/dist/2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz 100.0% extracting rustc/build/cache/2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz downloading https://static.rust-lang.org/dist/2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz 100.0% extracting rustc/build/cache/2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz building stage0 tar file now, this will take a while... orig-stage0 bootstrapping tarball created in ../rustc_1.61.0+dfsg1.orig-stage0.tar.xz containing the upstream compilers for amd64 arm64 You *probably* now want to do the following steps: 1. Add [!amd64 !arm64] to the rustc/cargo Build-Depends in d/control 2. Update d/changelog 3. Run `dpkg-source -b .` to generate a .dsc that includes this tarball. $ tar tvf ../rustc_1.61.0+dfsg1.orig-stage0.tar.xz drwxr-xr-x root/root 0 2022-10-13 11:34 2022-04-07/ -rw--- root/root 57248964 2022-04-07 14:44 2022-04-07/rustc-1.60.0-x86_64-unknown-linux-gnu.tar.xz -rw--- root/root 6585328 2022-04-07 14:41 2022-04-07/cargo-1.60.0-x86_64-unknown-linux-gnu.tar.xz -rw--- root/root 27569116 2022-04-07 14:44 2022-04-07/rust-std-1.60.0-x86_64-unknown-linux-gnu.tar.xz -rw-r--r-- root/root 0 2022-10-13 11:34 dpkg-source-dont-rename-parent-directory As you can see, only the x86_64 binary is present inside the stage0 tarball. To workaround this locally, I manually called $ PYTHONPATH=src/bootstrap debian/get-stage0.py then re-ran the source_orig-stage0 which packed the downloaded tarballs into the stage0 tarball.
Bug#1021666: mesa: Add wayland-protocols version >= 1.24 to Mesa's Build-Depends
Source: mesa Version: 22.2.0-1 Severity: normal Dear Maintainer, With older version of wayland-protocols package available (1.20), the build starts but fails late with: Dependency wayland-protocols found: NO found 1.20 but need: '>= 1.24' Invalid version of dependency, need 'wayland-protocols' ['>= 1.24'] found '1.20'. CMake binary for 1 is cached as not found CMake binary for machine 1 not found. Giving up. Run-time dependency wayland-protocols found: NO ../meson.build:2057:2: ERROR: Invalid version of dependency, need 'wayland-protocols' ['>= 1.24'] found '1.20'. Can we add a direct version to the wayland-protocols dependency of >= 1.24 to catch this error earlier? -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1021653: parted: prefer exclusively locking devices over calling udevadm settle
Package: parted Version: 3.5-2 Severity: important Dear Maintainer, Currently with debian/patches/udevadm-settle.patch, `udevadm settle` is called around the opening/closing of the block device. This is supposed to wait for udev to process device creation events and ensuring that the device nodes have been created. I don't think this call is needed, instead we should lock the device using flock(LOCK_EX) and hold the lock until we are done with the device. According to systemd documentation, https://systemd.io/BLOCK_DEVICE_LOCKING/ this is the correct way to stop udev from processing events on the block device while it is being modified. This method could also be pushed upstream to parted, there is an outstanding patch (long before systemd!) which could be used for inspiration: https://www.mail-archive.com/parted-devel@lists.alioth.debian.org/msg04119.html -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages parted depends on: ii libc6 2.35-1 ii libparted23.5-2 ii libreadline8 8.2~rc2-2 ii libtinfo6 6.3+20220423-2 parted recommends no packages. Versions of packages parted suggests: pn parted-doc -- no debconf information
Bug#1020690: fakemachine should depend on systemd-resolved
On Sun, 25 Sep 2022 12:25:27 +0100 Christopher Obbard wrote: > Package: fakemachine > Version: 0.0~git20210901.fc48786-1+b2 > Severity: important > > Dear Maintainer, > > The latest systemd packages do not include systemd-resolved; it was split out > into a seperate package. > > Because of this, on a machine which does not have systemd-resolved installed, > fakemachine no longer works as intended. > > Please add systemd-resolved as a runtime dependency to fakemachine. Turns out it is not as simple as including it as a dependency: installing systemd-resolved makes it the default name resolution service and could cause some users confusion. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288 for more detail.
Bug#1020691: debos should depend on systemd-resolved
merge 1020288 1020691 On Wed, 2022-10-05 at 14:36 +0700, Arnaud Rebillout wrote: > > > On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard > > wrote: > > > Because of this, on a machine which does not have > > > systemd-resolved installed, debos no longer works as > > > intended. > > > > > > Please add systemd-resolved as a runtime dependency to debos. > > > > It will fix debos but might break user's setup, or at least > surprise > > user, because systemd-resolved will take over name resolution > > on the machine where it's installed. > > > > Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288 > > This comment also applies to fakemachine bug: > https://bugs.debian.org/1020690 > Hi Arnaud, Thanks for shedding the extra light. This is not a nice bug ! I think we should ask the systemd maintainer if they'd accept a patch to make the enabling of systemd-resolved service a manual operation, or at least to split the binary into a separate package, something like systemd-standalone-resolved ?
Bug#1020691: debos should depend on systemd-resolved
Package: debos Version: 1.0.0+git20210707.c66a48d-2+b2 Severity: important Dear Maintainer, The latest systemd packages do not include systemd-resolved; it was split out into a seperate package. Because of this, on a machine which does not have systemd-resolved installed, debos no longer works as intended. Please add systemd-resolved as a runtime dependency to debos. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debos depends on: ii busybox1:1.35.0-2 ii debootstrap1.0.127 ii libc6 2.35-1 ii libglib2.0-0 2.74.0-1 ii libostree-1-1 2022.5-3 ii qemu-system-x861:7.1+dfsg-2 ii qemu-user-static 1:7.1+dfsg-2 ii systemd-container 251.4-3 Versions of packages debos recommends: ii bmap-tools 3.6-1 ii bzip2 1.0.8-5+b1 ii e2fsprogs 1.46.6~rc1-1 ii linux-image-amd64 5.19.6-1 ii mount 2.38.1-1 ii ovmf 2022.08-1 ii parted 3.5-2 ii udev 251.4-3 ii xz-utils 5.2.5-2.1 ii zip3.0-12 debos suggests no packages. -- no debconf information
Bug#1020690: fakemachine should depend on systemd-resolved
Package: fakemachine Version: 0.0~git20210901.fc48786-1+b2 Severity: important Dear Maintainer, The latest systemd packages do not include systemd-resolved; it was split out into a seperate package. Because of this, on a machine which does not have systemd-resolved installed, fakemachine no longer works as intended. Please add systemd-resolved as a runtime dependency to fakemachine. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fakemachine depends on: ii busybox 1:1.35.0-2 ii qemu-system-x86 1:7.1+dfsg-2 ii systemd 251.4-3 Versions of packages fakemachine recommends: ii e2fsprogs 1.46.6~rc1-1 ii linux-image-amd64 5.19.6-1 fakemachine suggests no packages. -- no debconf information
Bug#1019743: u-boot-menu: u-boot-update should read kernel parameters from /etc/kernel/cmdline
Hi Arnaud, > That sounds like an interesting thing to have indeed, I actually > started > working on this a while ago but didn't have the time/incentive to > push > it further. > > Attaching the (draft) patch I came up with in case it can help moving > forward. Thanks for the patch, I cleaned it up a little and pushed it to https://salsa.debian.org/debian/u-boot-menu/-/merge_requests/9 Let's hope for some feedback there. Cheers! Chris
Bug#1019743: u-boot-menu: u-boot-update should read kernel parameters from /etc/kernel/cmdline
Source: u-boot-menu Version: 4.1.0 Severity: wishlist Dear Maintainer, u-boot-update should read the kernel cmline parameters from /etc/kernel/cmdline when updating the extlinux configuration. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017438: ITP: fluster -- Testing framework for multimedia decoder conformance
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: fluster Version : 1.0+git20220816.1257c21 Upstream Author : Pablo Marcos Oltra * URL : https://github.com/fluendo/fluster * License : LGPL Programming Lang: Python Description : Testing framework for multimedia decoder conformance Fluster is a testing framework written in Python for decoders conformance. It is composed of a CLI application that runs a number of test suites with the supported decoders. Its purpose is to check different decoder implementations against known test suites with known and tested results. It has been originally designed to check the conformance of H.265/HEVC decoders, but it also supports H.264/AVC and can be easily extended to add more decoders and test suites. It is useful for codec development to ensure that the decoder driver and userspace components are implemented correctly.
Bug#1013227: qjackctl cannot be installed on a pipewire only system
Another option is to use the qpwgraph package On 19 June 2022 14:36:27 BST, Daniel Savi wrote: >Package: qjackctl >Severity: important >X-Debbugs-Cc: pub...@gaess.ch > >Dear Maintainer, > >I'm running a system on bookworm with pipewire only as sound server. According >to the pipewire documentation, qjackctl would be the best tool to manage sound >pipes also with pipewire. Because qjackctl depends on jackd only, it cannot be >installed without installing jackd as well. Please add an alternative >dependency for pipewire as well. >Kind regards and thanks for the good work. > > >-- System Information: >Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') >Architecture: amd64 (x86_64) > >Kernel: Linux 5.18.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) >Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), >LANGUAGE=de_CH:de >Shell: /bin/sh linked to /usr/bin/dash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled > >Versions of packages qjackctl depends on: >pn jackd >ii libasound21.2.6.1-2+b1 >ii libc6 2.33-7 >ii libgcc-s1 12.1.0-2 >ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-1 >ii libqt5core5a 5.15.2+dfsg-16+b2 >ii libqt5dbus5 5.15.2+dfsg-16+b2 >ii libqt5gui55.15.2+dfsg-16+b2 >ii libqt5network55.15.2+dfsg-16+b2 >ii libqt5widgets55.15.2+dfsg-16+b2 >ii libqt5xml55.15.2+dfsg-16+b2 >ii libstdc++612.1.0-2 > >qjackctl recommends no packages. > >Versions of packages qjackctl suggests: >pn pulseaudio-utils >
Bug#1012786: libcamera: Fails to build from source
On 14/06/2022 15:35, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! On Tue, 14 Jun 2022 at 05:26, Christopher Obbard wrote: Hi! I propose a patch to potentially fix this: https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6 The use of the depreciated function could even be fixed in upstream, it could be worth updating the package from upstream? No, upstream is doing the right thing. Their builds ought to fail in this case. We are the ones that should disable this flag, as done. What you really need to do is take this issue to upstream so they use the newer interfaces if possible (ie, avoid the deprecation warning). Right, what I originally meant was: "perhaps upstream have fixed this by using the correct gstreamer function instead of a depreciated one, maybe we should check if upstream have done that". For the record, it turns out that upstream have: https://git.libcamera.org/libcamera/libcamera.git/commit/test/gstreamer/gstreamer_multi_stream_test.cpp?id=4085372c517e1527114dc4098194c3ae3b973ba0 So, if we update to the latest version of libcamera, everything is fine again for future :-). I don't mind doing an update to libcamera HEAD, if Andrew would like some help. Cheers! Chris
Bug#1012786: libcamera: Fails to build from source
Hi! I propose a patch to potentially fix this: https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6 The use of the depreciated function could even be fixed in upstream, it could be worth updating the package from upstream? @Andrew: can you review the patch above? Also, I can help with updating from upstream if you would like. Chris On 14/06/2022 03:02, Lisandro Damián Nicanor Pérez Meyer wrote: Source: libcamera Version: 0~git20200629+e7aa92a-8 Severity: serious Justification: Fails to build form source X-Debbugs-Cc: lisan...@debian.org Trying to fix a bug in libcamera I found it's currently failing to build from source. Seems it's taking deprecation warnings as errors. Log follows. Kinds regards, Lisandro. ../test/gstreamer/gstreamer_multi_stream_test.cpp: In member function ‘virtual int GstreamerMultiStreamTest::run()’: ../test/gstreamer/gstreamer_multi_stream_test.cpp:90:76: error: ‘GstPad* gst_element_get_request_pad(GstElement*, const gchar*)’ is deprecated: Use 'gst_element_request_pad_simple' instead [-Werror=deprecated-declarations] 90 | g_autoptr(GstPad) request_pad = gst_element_get_request_pad(libcameraSrc_, "src_%u"); | ~~~^ In file included from /usr/include/gstreamer-1.0/gst/gstbin.h:27, from /usr/include/gstreamer-1.0/gst/gst.h:35, from ../test/gstreamer/gstreamer_multi_stream_test.cpp:13: /usr/include/gstreamer-1.0/gst/gstelement.h:1042:25: note: declared here 1042 | GstPad* gst_element_get_request_pad (GstElement *element, const gchar *name); | ^~~ cc1plus: all warnings being treated as errors [246/390] /usr/bin/meson --internal symbolextractor '/<>/obj-x86_64-linux-gnu' src/libcamera/base/libcamera-base.so.0.0.0 src/libcamera/base/libcamera-base.so.0.0.0 src/libcamera/base/libcamera-base.so.0.0.0.p/libcamera-base.so.0.0.0.symbols [247/390] ccache c++ -Itest/stream/stream_formats.p -Itest/stream -I../test/stream -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ test/stream/stream_formats.p/stream_formats.cpp.o -MF test/stream/stream_formats.p/stream_formats.cpp.o.d -o test/stream/stream_formats.p/stream_formats.cpp.o -c ../test/stream/stream_formats.cpp [248/390] ccache c++ -Itest/serialization/control_serialization.p -Itest/serialization -I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBCAMERA_BASE_PRIVATE -MD -MQ test/serialization/control_serialization.p/serialization_test.cpp.o -MF test/serialization/control_serialization.p/serialization_test.cpp.o.d -o test/serialization/control_serialization.p/serialization_test.cpp.o -c ../test/serialization/serialization_test.cpp [249/390] ccache c++ -Itest/serialization/ipa_data_serializer_test.p -Itest/serialization -I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBCAMERA_BASE_PRIVATE -MD -MQ test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o -MF test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o.d -o test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o -c ../test/serialization/serialization_test.cpp [250/390] ccache c++ -Itest/serialization/control_serialization.p -Itest/serialization -I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBCAMERA_BASE_PRIVATE -MD -MQ test/serialization/control_serialization.p/control_serialization.cpp.o -MF test/serialization/control_serialization.p/control_serialization.cpp.o.d -o
Bug#1011244: labgrid: Labgrid should depend on python3-paho-mqtt
Package: labgrid Version: 0.4.1-3 Severity: normal Dear Maintainer, Please add python3-paho-mqtt as a dependency to the package. It is required when using labgrid-client to connect to a remote mqtt broker. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages labgrid depends on: ii iproute2 5.15.0-1 ii python3 3.10.4-1+b1 ii python3-labgrid 0.4.1-3 ii socat1.7.4.1-3 labgrid recommends no packages. labgrid suggests no packages. -- no debconf information
Bug#1009362: ITP: qdl -- tool to flash images to Qualcomm processors
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qdl Version : 1.0 Upstream Author : Bjorn Andersson * URL : https://github.com/andersson/qdl * License : BSD-3-clause Programming Lang: C Description : tool to flash images to Qualcomm processors This package provides a tool to flash signed images to various Qualcomm processors which support the Emergency Download Mode (EDL) mode of operation.
Bug#966178: ITP: rkdeveloptool -- tools for working with Rockchip ARM processors through the rockusb protocol
Hi Dylan, I have packaged rkdeveloptool (originally a really long time ago - finally found some time to refresh things today!) and the source is available here: https://salsa.debian.org/obbardc/rkdeveloptool Can I request a review and potentially an upload if all is good ? I guess this time it would be best to move it to the debian salsa namespace first - I do not have access there (yet?). Thanks and all the best, Chris
Bug#1007108: Fwd: ITP: qpwgraph -- User interface for controlling the PipeWire Graph
Hi Dylan, On 11/03/2022 21:55, Dylan Aïssi wrote: I had a look at it and of course it is good, nothing that could prevent me to upload it. Thank you for looking, your nitpicks are appreciated, since it helps me to become a better packager! - salsa-ci.yml is not needed anymore as we can directly use the config file from the salsa team: https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md#basic-use Right, I initially used dh_make which generated that salsa-ci.yml file. I've now removed it from the repo. Do you think it is worth opening a bug/merge request there to either remove the generated file or add a comment about it not being needed any more? - If you plan to maintain this package under the umbrella of the Debian Multimedia Team, you need to move the git repo under the team namespace and update the d/control fields accordingly. Just created a repo for you: salsa.debian.org:multimedia-team/qpwgraph.git I've pushed the source there, thanks! - Is there a specific reason to target the upstream dev website instead of the gitlab repo in the d/watch file? I guess he can forget to update it contrary to its gitlab repo. I did think about that, but most other packages I have seen target the upstream's website in the watch file. For the record, the upstream tarball on the author's website doesn't include the gitlab-ci file or some other bits, so they're not the same archive as what you would download from gitlab. - The history of your master and upstream branches is uncommon, I think you cloned the upstream repo and then imported the upstream tarball with gbp? It would be cleaner to just create these branches using gbp import-orig. Right, I wanted to experiment with keeping the upstream git history (like the pipewire packaging) rather than just importing all of the files in a single commit like how import-orig would in the usual case. I did that by: $ git init $ git remote add upstream g...@gitlab.freedesktop.org:rncbc/qpwgraph.git $ git checkout -b upstream v0.2.2 $ gbp import-orig --upstream-vcs-tag v0.2.2 --pristine-tar ../qpwgraph-0.2.2.tar.gz I have recreated those branches using import-orig without the git history, so hopefully it is a bit clearer now. Thanks! Chris
Bug#1007108: ITP: qpwgraph -- User interface for controlling the PipeWire Graph
Package: wnpp Severity: wishlist Owner: Christopher Obbard X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: qpwgraph Version : 0.2.2 Upstream Author : Rui Nuno Capela * URL : https://gitlab.freedesktop.org/rncbc/qpwgraph * License : GPL-2+ Programming Lang: C++ Description : User interface for controlling the PipeWire Graph qpwgraph is a graph manager dedicated to PipeWire (https://pipewire.org), using the Qt C++ framework (https://qt.io), based and pretty much like the same of QjackCtl (https://qjackctl.sourceforge.io).
Bug#1001766: oomd: ships both ./lib/systemd/system/oomd.service & ./usr/lib/systemd/system/oomd.service
Hi! Got a different error (with the same cause) when installing 0.5.0-1 using apt: Unpacking oomd (0.5.0-1+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-46e3FG/48-oomd_0.5.0-1+b1_amd64.deb (--unpack): unable to open '/usr/lib/systemd/system/oomd.service.dpkg-new': No such file or directory Looks like the package builds OK, but lintian fails: $ gbp clone https://salsa.debian.org/yangfl-guest/oomd.git $ cd oomd $ gbp buildpackage -uc -us ... Now running lintian oomd_0.5.0-1_amd64.changes ... E: oomd: file-in-root-and-usr lib/systemd/system/oomd.service usr/lib/systemd/system/oomd.service ... This is probably due to both oomd and the package shipping a (different!) service file: src/oomd/etc/oomd.service.in debian/oomd.service I've prepared a merge request to drop the upstream service (since the package's version is better) at: https://salsa.debian.org/yangfl-guest/oomd/-/merge_requests/3 Thank you! Christopher Obbard
Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)
Hi Diederik, > FTR: it's not unwillingness to help, but apart from reporting the issue > I'm not able to further help in any meaningful way to diagnose it. > But as stated before, if someone provides a .deb file with a/the fix, > I'm happy to test it. We're facing the same (similar?) problem with Debos - in some cases the qemu-user process seems to segfault. Looks like a new version of qemu is in experimental - which has some changes to linux-user/mmap.c Perhaps it would be a good idea to see if the bug is still present in 6.0? Thanks, Chris
Bug#981840: libslirp-helper crashes a few seconds after connection
Package: libslirp-helper Version: 4.3.0-2 Severity: grave Justification: renders package unusable Dear Maintainer, libslirp-helper crashes a few seconds after connection without any explanation on stdout or stderr, even with --debug flag set and RUST_BACKTRACE enabled. Debos and Fakemachine use libslirp-helper under the hood for networking, to create a bridge network for the inner virtual machine to the outside world. This can be tested by installing the fakemachine package and running fakemachine using the uml backend, then trying to connect to the network: $ fakemachine --backend uml wget http://google.com As you can see, the libslirp-helper process which is started by fakemachine quits. >From investigation, I think this is because libslirp-helper was patched to be compiled with an older version of the mio crate (0.6.16) while the libslirp-helper Cargo.toml requires a newer version of mio (0.6.19). These dependencies for this package were relaxed since mio version 0.6.16 was already packaged for debian. When manually building the package with mio version 0.6.16, I get the same error described above. So I am pretty sure that bumping mio will sort this out. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libslirp-helper depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-3 ii libslirp0 4.4.0-1 libslirp-helper recommends no packages. libslirp-helper suggests no packages. -- no debconf information
Bug#980864: Linux 5.10.9-1 is prevented from migrating to testing because build fails on mipsel
Hi Salvatore, On Sat, 23 Jan 2021 at 13:13, Salvatore Bonaccorso wrote: > > Christopher, > > On Sat, Jan 23, 2021 at 11:24:21AM +, Christopher Obbard wrote: > > Package: src:linux > > Version: 5.10.9-1 > > Severity: normal > > > > According to the tracker page for the linux package, > > https://tracker.debian.org/pkg/linux > > > > under issues preventing migration is one important entry: > > - missing build on mipsel > > > > Looking at the build logs, it seems that the build didn't even start > > whereas on previous uploads it built fine for the architecture. > > Give it time :). It would not have migrated yet anyway. You can see on > the tracker page it is only 1 day old. I was only uploaded recently, > and mipsel build takes time (on eberlin were it currently builds > usually around 1d and 20h). right, I see on the buildd status page that it is "Building" which really means the package is waiting to build or building. I guess it's the former since no logs are available yet ;-). Thanks again for explaining, and sorry for the noise: the Debian systems can be quite confusing for a relative newcomer and a little explanation is very helpful! > > I will close the bug already, in case it FTBFS on mipsel we can look > at it. > > Regards, > Salvatore
Bug#980864: Linux 5.10.9-1 is prevented from migrating to testing because build fails on mipsel
Package: src:linux Version: 5.10.9-1 Severity: normal According to the tracker page for the linux package, https://tracker.debian.org/pkg/linux under issues preventing migration is one important entry: - missing build on mipsel Looking at the build logs, it seems that the build didn't even start whereas on previous uploads it built fine for the architecture. thanks!
Bug#980552: Can't install kodi-pvr-hts on unstable
Package: kodi-pvr-hts Version: 8.1.2+ds1-1 Can't install the package, it complains about kodi-api-pvr, which I cannot find manually :-/. $ apt-cache show kodi-pvr-hts Package: kodi-pvr-hts Version: 8.1.2+ds1-1 $ sudo apt-get install kodi-pvr-hts Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: kodi-pvr-hts : Depends: kodi-api-pvr (< 7.1.0) E: Unable to correct problems, you have held broken packages. thanks!
Bug#979759: bump user-mode-linux using linux-source version 5.10.5-1 (or greater)
Package: user-mode-linux Version: 5.10-um1 Dear maintainers, Could you bump user-mode-linux package using linux-source package version 5.10.5-1 or greater? Linux 5.10.5 contains some extra backported patches for Debos, Debian Image Generator, and it's user-mode-linux backend. Debos currently allows to build images using a virtual machine with KVM, which usually isn't available for use on unprivileged cloud machines. On machines where these unprivileged cloud machines are used, Debos can either run directly on the host or inside a user-mode-linux "container". You can read some more about Debos and the UML backend here: https://github.com/go-debos/debos thanks! Christopher Obbard
Bug#979703: user-mode-linux should track stable kernel release
Hi Ritesh, On 10/01/2021 16:58, Ritesh Raj Sarraf wrote: Hi Christopher, Thank you for the patch. On Sun, 2021-01-10 at 12:29 +, Christopher Obbard wrote: The package user-mode-linux is built from the debian package linux- source which follows semantic versioning guidelines. The version used for the user-mode-linux package isn't descriptive enough, only using the major and minor release and dropping the minor release. The package should have the same version as the version of linux- source used to build the binary package. Consider: $ apt-cache show user-mode-linux | grep 'Version\|Built-Using' Version: 5.10um1 Built-Using: linux (= 5.10.4-1) $ linux --version 5.10.4 Yes. Otherwise, it would warrant a version bump with every update. As you already mention, Built-Using will give the exact version. > This can result in the user-mode-linux package getting out of sync compared to the linux-source package, potentially loosing some useful patches, bug-fixes and security updates along the way. Since the linux-source package also includes debian-specific kernel patches, it is best to track the linux-source version rather than kernel.org version. Well, the way it has been managed so far is the maintainer and other interested users keeping an eye on the updates to linux-source package and request a (binary-only) rebuild of the user-mode-linux package, which then picks up the latest linux-source packages' changes. Ideally, I would like to see an automated way of doing this but so far this has been done manually. In the longer run, in the most ideal scenario, user-mode-linux should be built as one of the targets of the linux package itself. But that hasn't happened at all. I've written a quick-and-dirty watch file to attempt to track the linux package tags: https://salsa.debian.org/uml-team/user-mode-linux/-/merge_requests/7 Thanks. I have merged it into the packaging repository. So this should now give a nice notifier on the Debian Tracker page, when the linux- source package is newer. But requesting a rebuild would still be a manual step. Right, that all makes sense. In the meantime a rebuild of user-mode-linux for Linux 5.10.5 would resolve my immediate issue, so I will open a new bug for that. I guess resolving #837920 (to build from src:linux) would also resolve this bug: so I am happy for you to close this as a duplicate of #837920. thanks! Christopher Obbard
Bug#979703: user-mode-linux should track stable kernel release
Package: user-mode-linux Version: 5.10-um1 The package user-mode-linux is built from the debian package linux-source which follows semantic versioning guidelines. The version used for the user-mode-linux package isn't descriptive enough, only using the major and minor release and dropping the minor release. The package should have the same version as the version of linux-source used to build the binary package. Consider: $ apt-cache show user-mode-linux | grep 'Version\|Built-Using' Version: 5.10um1 Built-Using: linux (= 5.10.4-1) $ linux --version 5.10.4 This can result in the user-mode-linux package getting out of sync compared to the linux-source package, potentially loosing some useful patches, bug-fixes and security updates along the way. Since the linux-source package also includes debian-specific kernel patches, it is best to track the linux-source version rather than kernel.org version. I've written a quick-and-dirty watch file to attempt to track the linux package tags: https://salsa.debian.org/uml-team/user-mode-linux/-/merge_requests/7 thanks, Christopher Obbard
Bug#971920: nextcloud-desktop: Not showing tray icon on Xfce
For me on XFCE the tray icon appears but clicking on it does nothing. One has to right click and go to settings for it to open Thanks! Chris On Fri, 9 Oct 2020, 20:03 Frank Lanitz, wrote: > Package: nextcloud-desktop > Version: 3.0.1-3 > Severity: normal > > Dear Maintainer, > > This issue was reported as part of #969576 but I guess somehow it was > missed out. > However, when starting the nextcloud desktop client the tray icon is not > apparing at the Xfce tray plugin. Unfortunately I cannot find anything > inside neither journal nor xsession-error-log. > > Thanks, Frank > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages nextcloud-desktop depends on: > ii libc6 2.31-3 > ii libcloudproviders0 0.3.0-3 > ii libgcc-s1 10.2.0-13 > ii libglib2.0-0 2.66.0-2 > ii libnextcloudsync0 3.0.1-3 > ii libqt5core5a 5.14.2+dfsg-6 > ii libqt5dbus55.14.2+dfsg-6 > ii libqt5gui5 5.14.2+dfsg-6 > ii libqt5keychain10.10.0-1 > ii libqt5network5 5.14.2+dfsg-6 > ii libqt5qml5 5.14.2+dfsg-3 > ii libqt5quick5 5.14.2+dfsg-3 > ii libqt5quickcontrols2-5 5.14.2+dfsg-2 > ii libqt5sql5-sqlite 5.14.2+dfsg-6 > ii libqt5svg5 5.14.2-2 > ii libqt5webenginecore5 5.14.2+dfsg1-5 > ii libqt5webenginewidgets55.14.2+dfsg1-5 > ii libqt5webkit5 5.212.0~alpha4-5 > ii libqt5widgets5 5.14.2+dfsg-6 > ii libstdc++6 10.2.0-13 > ii nextcloud-desktop-common 3.0.1-3 > ii nextcloud-desktop-l10n 3.0.1-3 > ii qml-module-qtgraphicaleffects 5.14.2-2 > ii qml-module-qtqml-models2 5.14.2+dfsg-3 > ii qml-module-qtquick-controls2 5.14.2+dfsg-2 > ii qml-module-qtquick-layouts 5.14.2+dfsg-3 > ii qml-module-qtquick-window2 5.14.2+dfsg-3 > ii qml-module-qtquick25.14.2+dfsg-3 > > Versions of packages nextcloud-desktop recommends: > ii nextcloud-desktop-doc 3.0.1-3 > > nextcloud-desktop suggests no packages. > > -- no debconf information > >
Bug#966178: ITP: rkdeveloptool -- tools for working with Rockchip ARM processors through the rockusb protocol
Package: wnpp Severity: wishlist Owner: Christopher Obbard * Package name: rkdeveloptool Version : 1.3+git20190701.6e92ebc-1 Upstream Author : Kever Yang * URL : http://opensource.rock-chips.com/wiki_Rkdeveloptool * License : GPL-2.0 Programming Lang: C++ Description : tools for working with Rockchip ARM processors through the rockusb protocol This package provides tools to communicate with various Rockchip ARM processors which support the RockUSB protocol (e.g rk3288, rk3328, rk3399 ...). The tool includes support to interact with the processors' low-level bootrom (MaskROM) as well as interact with the recovery or firmware-download protocol rockusb. This makes it possible to upload firmware to flash, download firmware from flash, erase flash, reset the device, read manufacturing information from the processor as well as other commands. This package is useful for anyone performing low-level debugging on Rockchip devices. Currently, there are no other implementations of the rockusb protocol available in Debian so manually compiling from source is currently required for anyone wanting to upload images to their Rockchip board and a package would make this process a lot simpler. I am looking for a sponsor for this package.
Bug#964036: linux: Please set CONFIG_HWLAT_TRACER=y
Source: linux Severity: wishlist Dear Maintainer, Setting CONFIG_HWLAT_TRACER=y enables a tracer to detect hardware latencies with no overhead when not used. It is not designed to be run on a production system, but is a useful tracer to use in embedded systems. Other distros enable this configuration option, I see no security issues or performance issues for users since this is by-default turned off so has to be enabled at runtime. Thanks, Chris -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#953103: virtualbox does not install in sid
Package: virtualbox Version: 6.1.4-dfsg-1 Severity: important Dear maintainer, upon upgrading my system Virtualbox no longer installs. $ sudo apt-get install virtualbox Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: virtualbox : Depends: python3 (< 3.8) but 3.8.2-1 is to be installed Recommends: virtualbox-qt (= 6.1.4-dfsg-1) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Thanks! Chris
Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java
Hi, On Fri, 3 Jan 2020 at 17:52, Rene Engelhard wrote: > > Hi, > > On Fri, Jan 03, 2020 at 06:36:56PM +0100, Rene Engelhard wrote: > > > The following additional packages will be installed: > > >libjuh-java libjurt-java libridl-java libunoloader-java > > > The following NEW packages will be installed: > > >libjuh-java libjurt-java libridl-java libunoloader-java > [...] > > I wonder how you got into this. Looks you didn't upgrade to 6.4 yet > before so that it does flag libjuh-java libjurt-java libridl-java > libunoloader-java as *additional* packages? those four depends appear to be coming from the upgrade of libreoffice-java-common libreoffice has been upgraded to the latest version > > I am not sure what a dist-upgrade will do here and Replaces: vice-versa > > might be problematic, so it might be you need to upgrade ure when it is > > available and then continue with a normal upgrade (maybe it even works > > in one -f or dist-upgrade, but not sure). > > Actually #debian-devel says it should work, so let's test... the dist-upgrade won't work until the four packages are installed, which won't happen because they conflict with ure... which is required by most of the libreoffice suite :-) thanks Chris > > Regards, > > Rene
Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java
On Fri, 3 Jan 2020 17:07:33 +0100 Rene Engelhard wrote: > On Fri, Jan 03, 2020 at 04:49:23PM +0100, Thorsten Glaser wrote: > > Package: ure > > Version: 6.4.0~rc1-5 > > Followup-For: Bug #947907 > > > > It’s more than just libjuh-java: > > Yes. > > As was already said in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947907#34 (this bug!) > and the bugs merged with it (and the corresponding commit.) oooh dear, just has this one myself. $ sudo apt --fix-broken install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: libjuh-java libjurt-java libridl-java libunoloader-java The following NEW packages will be installed: libjuh-java libjurt-java libridl-java libunoloader-java 0 upgraded, 4 newly installed, 0 to remove and 123 not upgraded. 37 not fully installed or removed. Need to get 0 B/1,138 kB of archives. After this operation, 1,351 kB of additional disk space will be used. Do you want to continue? [Y/n] (Reading database ... 124615 files and directories currently installed.) Preparing to unpack .../libjuh-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libjuh-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libjuh-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/juh.jar', which is also in package ure 6.4.0~rc1-5 Preparing to unpack .../libjurt-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libjurt-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libjurt-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/jurt.jar', which is also in package ure 6.4.0~rc1-5 Preparing to unpack .../libridl-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libridl-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libridl-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/ridl.jar', which is also in package ure 6.4.0~rc1-5 Preparing to unpack .../libunoloader-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libunoloader-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libunoloader-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/unoloader.jar', which is also in package ure 6.4.0~rc1-5 Errors were encountered while processing: /var/cache/apt/archives/libjuh-java_1%3a6.4.0~rc1-5_all.deb /var/cache/apt/archives/libjurt-java_1%3a6.4.0~rc1-5_all.deb /var/cache/apt/archives/libridl-java_1%3a6.4.0~rc1-5_all.deb /var/cache/apt/archives/libunoloader-java_1%3a6.4.0~rc1-5_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) > > Regards, > > Rene > >
Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites
On Thu, 2 Jan 2020 at 16:30, wrote: > > Yes, it is the same. > > Since this seems likely to only occur on some graphics hardware: What is your > graphics card? I run sid with a daily full-upgrade funnily this same thing used to happen about 6 months ago on my HD5850, so I got a RX580 which cured it until some time this week. I am using the driver provided by xserver-xorg-video-amdgpu Thanks Chris > > Regards, Thue > > Den tor. 2. jan. 2020 kl. 15.28 skrev Christopher Obbard : >> >> Hi, >> >> For me some videos (incl. your link) now have their colours changed to >> a funny yellow/red tinge. >> Is this similar to you? >> >> Cheers! >> >> On Sun, 22 Dec 2019 22:59:03 +0100 Thue wrote: >> > Package: chromium >> > Version: 79.0.3945.79-1 >> > Severity: normal >> > >> > Dear Maintainer, >> > The hardware video support seems to have broken in a recent update. E.g. >> > https://www.twitch.tv/videos/290265920 . >> > >> > Turning off "Use hardware acceleration when available" in the settings >> > fixes it. >> > >> > Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1036725 >> > >> > Regards, Thue >> > >> > >> > *** Reporter, please consider answering these questions, where appropriate >> > *** >> > >> >* What led up to the situation? >> >* What exactly did you do (or not do) that was effective (or >> > ineffective)? >> >* What was the outcome of this action? >> >* What outcome did you expect instead? >> > >> > *** End of the template - remove these template lines *** >> > >> > >> > -- System Information: >> > Debian Release: bullseye/sid >> > APT prefers unstable >> > APT policy: (500, 'unstable') >> > Architecture: amd64 (x86_64) >> > Foreign Architectures: i386 >> > >> > Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) >> > Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.UTF-8 (charmap=UTF-8), LANGUAGE= >> > (charmap=UTF-8) >> > Shell: /bin/sh linked to /bin/dash >> > Init: systemd (via /run/systemd/system) >> > LSM: AppArmor: enabled >> > >> > Versions of packages chromium depends on: >> > ii chromium-common 79.0.3945.79-1 >> > ii libasound2 1.1.9-1 >> > ii libatk-bridge2.0-0 2.34.1-2 >> > ii libatk1.0-0 2.34.1-1 >> > ii libatomic1 9.2.1-21 >> > ii libatspi2.0-02.34.0-3 >> > ii libavcodec58 7:4.2.1-2 >> > ii libavformat587:4.2.1-2 >> > ii libavutil56 7:4.2.1-2 >> > ii libc62.29-6 >> > ii libcairo-gobject21.16.0-4 >> > ii libcairo21.16.0-4 >> > ii libcups2 2.3.0-7 >> > ii libdbus-1-3 1.12.16-2 >> > ii libdrm2 2.4.100-4 >> > ii libevent-2.1-7 2.1.11-stable-1 >> > ii libexpat12.2.9-1 >> > ii libflac8 1.3.3-1 >> > ii libfontconfig1 2.13.1-2+b1 >> > ii libfreetype6 2.10.1-2 >> > ii libgcc1 1:9.2.1-21
Bug#945920: Random Chromium crashes
Hi, This is also occurring on two machines for me. The crashes are random but will happen after about 10 minutes of use, quite annoying... Thanks! Chris On Tue, 31 Dec 2019 18:27:13 +0100 (CET) Thorsten Bonow wrote: > On Mon, 30 Dec 2019 13:50:36 -0800 Eloston > wrote: > > [...] > > > $ ./debian/rules get-orig-source > > Hi, > > this fails for me: > > [...] > test ! -e debian || rm -rf debian > cp -r ../debian ./ > cp: cannot stat '../debian': No such file or directory > make: *** [debian/rules:212: get-orig-source] Error 1 > ./debian/rules get-orig-source 441.08s user 24.95s system 92% cpu > 8:25.08 total > > Files and directories: > $ ll > total 12K > drwxr-sr-x 50 toto staff 4.0K Dec 31 14:40 chromium-79.0.3945.79 > -rw-r--r-- 1 toto staff 2.9K Dec 31 14:30 > chromium-build-deps_79.0.3945.79-1_all.deb > -rw-r--r-- 1 toto staff 3.6K Dec 31 12:28 enable-tracing.patch > $ pwd > /usr/local/src/chromium/chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371 > > > Regards, > Toto > > -- > Sent from my GNU Emacs running on GNU/Linux > >
Bug#932935:
Also broken for me on Debian Sid amd64 with kernel version linux-image-4.19.0-5-amd64. Same error message. Selecting version 4.19.0-4 in the grub menu makes the error go away. This is a critical error and will no doubt break many systems so belongs to have an appropriate severity.
Bug#924358: Dependency problems with logind | consolekit
Package: lightdm Version: 1.26.0-4 Depends: logind [linux-any] | consolekit these packages are not in the buster/sid archives.
Bug#923289: Cannot install libgdk-pixbuf2.0-0 inside an armhf chroot
Package: libgdk-pixbuf2.0-0 Version: 2.38.0+dfsg-7 installing the package under an armhf chroot on amd64 results in the following error, the package is not configured properly and leads to icons missing from the desktop environment. > Setting up libgdk-pixbuf2.0-0:armhf (2.38.0+dfsg-7) ... > > (process:21627): GLib-ERROR **: 20:50:46.361: getauxval () failed: No such > file or directory > qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped > Trace/breakpoint trap The fix was to run the following commands (not in chroot -- on the real hardware): $ apt-get --reinstall install libgdk-pixbuf2.0-0 $ update-mime-database /usr/share/mime Note this previously worked about ~6 months ago. Cheers!
Bug#917609: installation did not include scanner drivers
Package: xsane Version: 0.999-6 Installed xsane package using apt-get on sid machine, but it did not work with my (cheap and good) Canon LiDE 120 until I installed sane-utils. Should sane-utils be a Depends of xsane? Cheers!
Bug#902185:
this has happened to me on both my laptop and pc when doing an upgrade. A reinstall of Debian on my main PC seemed to fix it. My laptop boots to the WM but with no keyboard/mouse. This is a grave bug.
Bug#901717: closed by Hideki Yamane (Bug#901717: fixed in debootstrap 1.0.104)
Hi Hideki, I can confirm this patch fixes the initial issue, but installing some packages with apt after gives me some issues: /lib/ld-linux-ar/lib/ld-linux-armhf.so.3: No such file or directory Version 1.0.101 does not cause these issues. I will investigate this more this week and get back to you. This may be a separate issue, though. Cheers! On 26 June 2018 at 13:21, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the debootstrap package: > > #901717: debootstrap: Version 1.0.102 breaks use of file mirrors > > It has been closed by Hideki Yamane . > > 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 Hideki Yamane > by > replying to this email. > > > -- > 901717: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901717 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > -- Forwarded message -- > From: Hideki Yamane > To: 901717-cl...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 26 Jun 2018 12:19:15 + > Subject: Bug#901717: fixed in debootstrap 1.0.104 > Source: debootstrap > Source-Version: 1.0.104 > > We believe that the bug you reported is fixed in the latest version of > debootstrap, 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 901...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Hideki Yamane (supplier of updated debootstrap 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: Sun, 24 Jun 2018 20:41:13 +0900 > Source: debootstrap > Binary: debootstrap debootstrap-udeb > Architecture: source > Version: 1.0.104 > Distribution: unstable > Urgency: medium > Maintainer: Debian Install System Team > Changed-By: Hideki Yamane > Description: > debootstrap - Bootstrap a basic Debian system > debootstrap-udeb - Bootstrap the Debian system (udeb) > Closes: 899155 901717 > Changes: > debootstrap (1.0.104) unstable; urgency=medium > . >* Fix /etc/machine-id mount issue (Closes: #899155) >* Fix regression with file:/// mirror (Closes: #901717) > Checksums-Sha1: > d3d1af265af066a248def5f59ed60549ca5301d1 2017 debootstrap_1.0.104.dsc > 6dce2e5390dc1d1bdcf6ca270615775c9f14be14 73264 debootstrap_1.0.104.tar.gz > 074ab4b2560e4e1bb2f08e1fa35850447236ebb5 5854 > debootstrap_1.0.104_amd64.buildinfo > Checksums-Sha256: > 8b95ca08935bb002d726ff5c12ff99e0a5e37a1f0267d5ebd38cecefb17bc9c7 2017 > debootstrap_1.0.104.dsc > fd01743c9d87aef2621c88420f896c67342c85ce24d289fad021518755801b28 73264 > debootstrap_1.0.104.tar.gz > 9ee32dc182365e05cb9a97bc44e44b83ce78c565d2dd575e880abb71e95b5441 5854 > debootstrap_1.0.104_amd64.buildinfo > Files: > 3643a66fb173b612b5765e6a05c5b28b 2017 admin optional debootstrap_1.0.104.dsc > 10743679b4121c9a70a0ac9690882b5f 73264 admin optional > debootstrap_1.0.104.tar.gz > bba1d6c61b1ae14983721047f9cddda2 5854 admin optional > debootstrap_1.0.104_amd64.buildinfo > > -BEGIN PGP SIGNATURE- > > iQJHBAEBCgAxFiEEWOEiL5aWyIWjzRBMXTKNCCqqsUAFAlsvhQsTHGhlbnJpY2hA > ZGViaWFuLm9yZwAKCRBdMo0IKqqxQKU7EAC39+bVPMgYAMKPt7+Ke0hrya914noZ > BuZaaVaV/3vBFfWT5qsYQDw0W6gx3FBwlD7vSBpFb8uv4XmLLtkn6cOEgfXrfPvZ > dv8Y6G/UdT3cyggrlwM0fzI0jECVpx6pqk5/M8q44A+JoyU82M9sB4/FCQ/TLSM6 > 6tcAkJfoMNff3gUVvQ4UhYZfN1gEq2g/+l+wazh4D47d17gx0FSAlr6q40RP6nGn > CNG4DackiuiBdQI/z77pK5SqdXrhvGw7qKyFg1vKHVR6sh5fvKS+WXhvaziEXC3v > f8ixEBmNCtX6zxdGJt+eS8CERJtjcHscwsDMljZo8MuKxCDLiVamYq0JjHjPiB7p > 5LiLjvpdytI2oueo1omp2Io97L3aBnxAg5i+D7nDL0Z4/xuHsf5+CGAndkiPVSuC > NQF69zzY43wiaxUKDVyAnJ8qz/gb4Ao733255dBOYyN9ZbXHnMBJU46f17reM/Eg > hNR185Yvdjq0WewG4957rUyW9OVUxWaBzqSHltSb0qBhC2BuNittupdiHlTzagPe > 9a/sIw4bpyUIUE/4lGtLaAr+INPP3gk5ExksBe2yYEudUNTXwNnZvyODFww4NFK8 > Kxy/B31BP4tQutzrnmvoBIgSA/ObrbQyJWfyNcMT8KvWsiJll0Rgm3bsr3xhjoja > 7RwX8G/BXlYp8Q== > =GELe > -END PGP SIGNATURE- > > -- Forwarded message -- > From: Christopher Obbard > To: sub...@bugs.debian.org > Cc: > Bcc: > Date: Sun, 17 Jun 2018 12:07:22 +0100 > Subject: debootstrap: Version 1.0.102 brea
Bug#901717:
I have confirmed debootstrap 1.0.101 is unaffected, so I am using this version in the mean time. Okay, so thinking about it I think inserting debootstrap.invalid in the sources.list was a pretty good way of doing it for the case of anything that isn't an http/https mirror. Can we do that instead of the current patch? Cheers!
Bug#901718: debootstrap: Version 1.0.102 breaks use of file mirrors
Package: debootstrap Version: 1.0.102 Severity: important This is a new bug introduced in 1.0.101 We use debootstrap with a custom file:// mirror to strap cross-arch images for SBCs, with a second call to debootstrap --second-stage. in this format: debootstrap --foreign --arch="armhf" "buster" "test" "file://$PWD/repo" cp /usr/bin/qemu-arm-static test/usr/bin/ chroot test/ /debootstrap/debootstrap --second-stage Normally, debootstrap is used with http and https mirrors so this bug will not be an issue for most users. In git commit #48d77abf3a4209f7cff72aec20f618e086169aa7 the following change breaks debootstrap for my use: if there is no http or https mirror defined, revert MIRRORS back to DEF_MIRROR. This is dangerous because now --second-stage will always revert to DEF_MIRROR. we should write the file mirror URI to sources.list When trying to setup packages using setup_available, debootstrap exits and the log complains it cannot find the cached Packages file from DEF_MIRROR. I think debootstrap in --second-stage mode should read the mirror URI from sources.list or read the mirror URI from a new file called /debootstrap/mirror. What do you think? Cheers! Christopher Obbard
Bug#901717: debootstrap: Version 1.0.102 breaks use of file mirrors
Package: debootstrap Version: 1.0.102 Severity: important This is a new bug introduced in 1.0.101 We use debootstrap with a custom file:// mirror to strap cross-arch images for SBCs, with a second call to debootstrap --second-stage. in this format: debootstrap --foreign --arch="armhf" "buster" "test" "file://$PWD/repo" cp /usr/bin/qemu-arm-static test/usr/bin/ chroot test/ /debootstrap/debootstrap --second-stage Normally, debootstrap is used with http and https mirrors so this bug will not be an issue for most users. In git commit #48d77abf3a4209f7cff72aec20f618e086169aa7 the following change breaks debootstrap for my use: if there is no http or https mirror defined, revert MIRRORS back to DEF_MIRROR. This is dangerous because now --second-stage will always revert to DEF_MIRROR. we should write the file mirror URI to sources.list When trying to setup packages using setup_available, debootstrap exits and the log complains it cannot find the cached Packages file from DEF_MIRROR. I think debootstrap in --second-stage mode should read the mirror URI from sources.list or read the mirror URI from a new file called /debootstrap/mirror. What do you think? Cheers!
