Bug#1081867: guile-ssh: FTBFS: ../../../../libguile-ssh/session-func.c:237:11: error: two or more data types in declaration specifiers

[Vagrant Cascadian]

Control: forwarded 1081867 https://github.com/artyom-poptsov/guile-ssh/issues/42

On 2024-09-15, Santiago Vila wrote:
> During a rebuild of all packages in unstable, your package failed to build:
...
> In file included from /usr/include/libssh/callbacks.h:30,
>   from ../../../../libguile-ssh/session-func.c:26:
> ../../../../libguile-ssh/session-func.c: In function 'set_bool_opt':
> ../../../../libguile-ssh/session-func.c:237:11: error: two or more data types 
> in declaration specifiers
>237 |   int32_t bool;
>|   ^~~~
> ../../../../libguile-ssh/session-func.c:237:3: warning: useless type name in 
> empty declaration
>237 |   int32_t bool;
>|   ^~~
> ../../../../libguile-ssh/session-func.c:241:8: error: expected identifier or 
> '(' before '=' token
>241 |   bool = scm_to_bool (value);
>|^
> ../../../../libguile-ssh/session-func.c:242:43: error: expected expression 
> before '_Bool'
>242 |   return ssh_options_set (session, type, &bool);
>|   ^~~~
> ../../../../libguile-ssh/session-func.c:243:1: warning: control reaches end 
> of non-void function [-Wreturn-type]
>243 | }
>| ^

This appears due to the update of libssh to 0.11.x. 0.10.x still built
fine when I checked a couple weeks ago, when I forwarded the issue
upstream.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1081078: guix: FTBFS: FAIL: tests/store.scm - export/import several paths

[Vagrant Cascadian]

Control: reassign 1081078 guile-gcrypt
Control: affects 1081078 guix

> On 2024-09-08, Santiago Vila wrote:
>> FAIL: tests/nar.scm - restore-file-set (signed, valid)
>> FAIL: tests/nar.scm - restore-file-set with directories (signed, valid)
>> FAIL: tests/nar.scm - restore-file-set (corrupt)
...
>> FAIL: tests/store.scm - export/import several paths

The guix build failures were apparently caused by guile-gcrypt
presumably after the newer guile-3.0 upload that effectively downgraded
to guile 3.9.

Rebuilding guile-gcrypt and then building guix worked for me, at least,
so I uploaded a new version of guile-gcrypt to trigger a rebuild.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1081025: epoptes: implicit dependency on removed python3-distutils

[Vagrant Cascadian]

Control: forwarded 1081025 https://github.com/epoptes/epoptes/issues/193

On 2024-09-06, Vagrant Cascadian wrote:
> Running epoptes on debian trixie results in:
>
>   $ epoptes
>   Traceback (most recent call last):
> File "/usr/bin/epoptes", line 20, in 
>   from epoptes.ui import gui
> File "/usr/lib/python3/dist-packages/epoptes/ui/gui.py", line 8, in 
> 
>   from distutils.version import LooseVersion
>   ModuleNotFoundError: No module named 'distutils'
>
> python3-distutils was removed from Debian with python3-stdlib-extensions 
> 3.12.4-1:
>
>   
> https://tracker.debian.org/news/1543129/accepted-python3-stdlib-extensions-3124-1-source-into-unstable/

Alkis (a.k.a. upstream) suggested installing python3-setuptools and it
seemed to work... so there is at least a quick workaround.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1081025: epoptes: implicit dependency on removed python3-distutils

[Vagrant Cascadian]

Package: epoptes
Version: 23.08-1
Severity: serious
X-Debbugs-Cc: vagr...@debian.org

Running epoptes on debian trixie results in:

  $ epoptes
  Traceback (most recent call last):
File "/usr/bin/epoptes", line 20, in 
  from epoptes.ui import gui
File "/usr/lib/python3/dist-packages/epoptes/ui/gui.py", line 8, in 
  from distutils.version import LooseVersion
  ModuleNotFoundError: No module named 'distutils'

python3-distutils was removed from Debian with python3-stdlib-extensions 
3.12.4-1:

  
https://tracker.debian.org/news/1543129/accepted-python3-stdlib-extensions-3124-1-source-into-unstable/


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1073710: marked as pending in guix

[Vagrant Cascadian]

Control: tag -1 pending

Hello,

Bug #1073710 in guix reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/guix/-/commit/1cf003a48bcb2fa4d09776dd536e7425fe846606


debian/rules: Move systemd files into /usr/lib/systemd. (Closes: #1073710)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1073710

Bug#1067952: mes: FTBFS on armhf

[Vagrant Cascadian]

Control: forwarded 1067952 
https://lists.gnu.org/archive/html/bug-mes/2024-01/msg8.html

On 2024-03-29, Kentaro HAYASHI wrote:
> mes 0.26-1 fails to build on armhf.
>
> FYI:
>
> https://buildd.debian.org/status/fetch.php?pkg=mes&arch=armhf&ver=0.26-1&stamp=1704511792&raw=0

Yeah, forwarded this upstream in January, but have not yet found a fix.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1064748: guix: FTBFS: In procedure canonicalize-path: No such file or directory

[Vagrant Cascadian]

Control: fixed 1064748 1.4.0-6

Marking this as fixed in 1.4.0-6, although strictly speaking, this is
only worked around by disabling the tests, so the bug should remain
open.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1064748: guix: FTBFS: In procedure canonicalize-path: No such file or directory

[Vagrant Cascadian]

Control: forwarded 1064748 https://debbugs.gnu.org/69518
Control: tags 1064748 confirmed

The actual failed tests are:

test-name: fold-available-packages with/without cache
test-name: find-packages-by-name with cache
test-name: find-packages-by-name + version, with cache
test-name: find-package-locations with cache

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1052309: NMU fixing FTBFS, cross-building and reproducible builds bugs

[Vagrant Cascadian]

I've uploaded an NMU fixing several cross building and reproducible
builds bugs and an RC bug to DELAYED/10. The changes should also be
available via dgit.

debdiff follows:

diff -Nru lirc-0.10.1/debian/changelog lirc-0.10.1/debian/changelog
--- lirc-0.10.1/debian/changelog2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/changelog2023-12-05 15:52:45.0 -0800
@@ -1,3 +1,28 @@
+lirc (0.10.1-7.3) unstable; urgency=medium
+
+  [ Vagrant Cascadian ]
+  * Non-maintainer upload.
+  * tools: Do not embed build date and kernel version in various files.
+(Closes: #979019)
+  * debian/rules: Run build in the C.UTF-8 locale. (Closes: #979023)
+
+  [ Helmut Grohne ]
+  * Build verbosely by default. (Closes: #988907)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Normalize shipped tarball of python source code.
+(Closes: #979024)
+
+  [ Helmut Grohne ]
+  * Fix FTBFS when systemdsystemunitdir changes in systemd.pc.
+(Closes: #1052309)
+  * Fix build vs host confusion. (Closes: #1052309)
+  * Check for /dev/input using AC_CHECK_FILE. (Closes: #989304)
+  * Multiarchify python Build-Depends. (Closes: #989304)
+  * Export _PYTHON_SYSCONFIGDATA_NAME for setup.py. (Closes: #989304)
+
+ -- Vagrant Cascadian   Tue, 05 Dec 2023 
15:52:45 -0800
+
 lirc (0.10.1-7.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lirc-0.10.1/debian/control lirc-0.10.1/debian/control
--- lirc-0.10.1/debian/control  2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/control  2023-12-05 15:52:45.0 -0800
@@ -18,6 +18,7 @@
  kmod [linux-any],
  libasound2-dev [linux-any kfreebsd-any],
  libftdi1-dev,
+ libpython3-dev (>= 3.5),
  libsystemd-dev [linux-any],
  libudev-dev [linux-any],
  libusb-1.0-0-dev [!kfreebsd-any],
@@ -26,9 +27,9 @@
  man2html-base,
  pkg-config,
  portaudio19-dev,
- python3-dev (>= 3.5),
+ python3-dev:any (>= 3.5),
  python3-setuptools,
- python3-yaml,
+ python3-yaml:native,
  socat [!hurd-any],
  systemd [linux-any],
  xsltproc
diff -Nru lirc-0.10.1/debian/install lirc-0.10.1/debian/install
--- lirc-0.10.1/debian/install  2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/install  2023-12-05 15:52:45.0 -0800
@@ -1,7 +1,7 @@
 #! /usr/bin/dh-exec
 
 etc/lirc
-[linux-any] lib/systemd/*
+[linux-any] ${systemdsystemunitdir}
 [linux-any] usr/lib/tmpfiles.d/*
 [linux-any] usr/bin/lirc-make-devinput
 [linux-any] usr/bin/irpipe
diff -Nru 
lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch 
lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch
--- lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch 
1969-12-31 16:00:00.0 -0800
+++ lirc-0.10.1/debian/patches/check-for-devinput-using-ac_check_file.patch 
2023-12-05 15:52:45.0 -0800
@@ -0,0 +1,44 @@
+From: Helmut Grohne 
+Date: Mon, 31 May 2021 13:09:56 +0200
+X-Dgit-Generated: 0.10.1-7.3 54cb42673c340f60f85764753d13da093aad4baf
+Subject: Check for /dev/input using AC_CHECK_FILE.
+
+(Closes: #989304)
+
+---
+
+diff --git a/configure.ac b/configure.ac
+index 1d910b0..66f96aa 100644
+--- a/configure.ac
 b/configure.ac
+@@ -289,29 +289,12 @@ else
+ fi
+ 
+ AC_MSG_CHECKING(for devinput)
+-AC_RUN_IFELSE([AC_LANG_PROGRAM([[
+-  #include 
+-]],[[
+-  return access("/dev/input", R_OK) == 0 ? 0 : 1;
+-]])],[
++AC_CHECK_FILE([/dev/input],[
+   have_devinput="yes"
+   AC_MSG_RESULT(yes)
+ ],[
+   AC_MSG_RESULT(no)
+   have_devinput="no"
+-],[
+-  AS_IF([test x$DEVINPUT_HEADER = x -a x$enable_devinput = xyes], [
+-AC_MSG_ERROR([
+-  cannot cross-compile with devinput without DEVINPUT_HEADER
+-  defined, giving up
+-])
+-  ])
+-  if test -n "$DEVINPUT_HEADER" ; then
+-have_devinput="yes"
+-  else
+-have_devinput="no"
+-  fi
+-  AC_MSG_RESULT(yes)
+ ])
+ 
+ 
diff -Nru lirc-0.10.1/debian/patches/series lirc-0.10.1/debian/patches/series
--- lirc-0.10.1/debian/patches/series   2022-12-28 03:25:42.0 -0800
+++ lirc-0.10.1/debian/patches/series   2023-12-05 15:52:45.0 -0800
@@ -9,3 +9,5 @@
 0009-Replace-the-obsolete-get_event_loop-with-get_running.patch
 0010-Patch-configure.ac-to-support-passing-MODINFO.patch
 0011-yaml.load.diff
+tools-do-not-embed-build-date-and-kernel.patch
+check-for-devinput-using-ac_check_file.patch
diff -Nru 
lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch 
lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch
--- lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch   
1969-12-31 16:00:00.0 -0800
+++ lirc-0.10.1/debian/patches/tools-do-not-embed-build-date-and-kernel.patch   
2023-12-05 15:52:45.0 -0800
@@ -0,0 +1,59 @@
+From: Vagrant Cascadian 
+Date: Sat, 2 Jan 2021 00:01:20 +
+X-Dgit-Generated: 0.10.1-7.3 1f430917c5ab786478d575d9714dd4e19defd8e1
+Subject: tools: Do not embed build date and kernel version in v

Bug#1052724: u-boot: FTBFS: cc1: error: ‘-fcf-protection=full’ is not supported for this target

[Vagrant Cascadian]

On 2023-09-26, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
...
>> cc1: error: ‘-fcf-protection=full’ is not supported for this target
>> make[3]: *** [/<>/Makefile:1816: include/generated/env.in] 
>> Error 1

Because several of the qemu targets for the u-boot-qemu arch:all are
cross-built, when dpkg-buildflags enabled the hardening=+branch feature
by default, this broke some of the cross builds which do not support the
resulting -fcf-protection=full feature added to the default compiler
flags.

I have disabled this feature in git for now, although a better fix might
be preferred allowing this to be used on other targets where it did not
cause an issue.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1052724: marked as pending in u-boot

[Vagrant Cascadian]

Control: tag -1 pending

Hello,

Bug #1052724 in u-boot reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/u-boot/-/commit/8ecfe9557fcfd217c2df88f183a4c3b3144891eb


debian/rules: Disable hardening branch feature to fix arch:all build.
(Closes: #1052724)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1052724

Bug#1042918: reprotest: FTBFS with tox 4

[Vagrant Cascadian]

Control: tags 1042918 pending

On 2023-08-02, Stefano Rivera wrote:
> I thought we'd managed to avoid this, in #1035645, but we just did the
> transition, and I see reprotest is FTBFS:
...
> py311: commands[0] .pybuild/cpython3_3.11_reprotest/build> 
> .tox/py311/bin/python -m coverage r
> un --omit '.tox/*' --parallel -m py.test tests/
> __path__ attribute not found on 'py' while trying to find 'py.test'
> py311: exit 1 (0.09 seconds) /<>> .tox/py311/bin/python -m 
> coverage run --omit '.
> tox/*' --parallel -m py.test tests/ pid=7370
>   py311: FAIL code 1 (2.31=setup[2.22]+cmd[0.09] seconds)
>   evaluation failed :( (2.36 seconds)
> E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd 
> /<>/.
> pybuild/cpython3_3.11_reprotest/build; tox -c /<>/tox.ini 
> --sitepackages --instal
> lpkg 
> /<>/.pybuild/cpython3_3.11_reprotest/reprotest-0.7.25-py3-none-any.whl
>  -e py311 
> dh_auto_test: error: pybuild --test --test-tox -i python{version} -p 3.11 
> --test-tox returned exit code 13
>
>
> I'm guessing you want to replace py.test there with pytest.

Great suggestion! Worked for me locally and in salsa-ci.

Pushed to git:

  
https://salsa.debian.org/reproducible-builds/reprotest/-/commit/3d01047ae75ffc3fc30ad11aeec1a0dd9994d849

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

[Vagrant Cascadian]

On 2023-07-16, Simon McVittie wrote:
> On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote:
>> But, what matters here is the CTTE ruling in #1035831 -- for the time being,
>> packages must not move files between locations affected by the aliasing.
>
> If that happens in reality, then yes, that's bad, and reverting the change
> is a mitigation. What packages have this behaviour?
>
> We are going to need to bring back this change relatively early in the
> trixie cycle in any case, for the reasons given in the commit message.
> I have not yet analyzed whether we need this change before we can lift
> the moratorium on file moves, but I suspect we might.
>
>> Packages built in an usrmerged chroot place such files under /usr while
>> built without usrmerge into whatever place they were installed to -- which
>> is a direct breach of the ruling.
>
> Do you have examples of packages that differ in this way when built in
> a merged- or unmerged-/usr environment? I think we should treat this
> as a RC-for-trixie bug in those packages (and in fact I would have been
> tempted to call it RC for bookworm as well, again for the reasons given
> by the TC, even though during the trixie cycle it was mitigated by using
> unmerged-/usr fro buildds).
>
> During most of the bookworm cycle, https://reproducible-builds.org/ has
> been doing "build1" in unmerged-/usr and "build2" in merged-/usr, with
> differences tracked in
> 
> (that list is not necessarily complete, there can also be unidentified
> differences in
> ).

For what it is worth, there were various points during the bookworm
cycle where this was not being tested on reproducible builds
infrastructure, as the mechanisms to disable it changed several
times...

We used to just be able to build a non-usrmerge tarball, and then
install usrmerge in the second build, but I think usr-is-merged or some
similar package is installed out of the box now, and the inverse
operation is non-trivial.

... which lead to some of the identified issues being systematically
removed for packages that were otherwise reproducible (you could still
look through git history to find more, but some many may be actually
fixed).

There are differing opinions on weather reproducible builds test
infrastrure should test usrmerge variations at all, given the direction
of Debian, though any alternate test infrastructure would essentially
have to implement a reproducible builds style test to check for
differences...

After upgrading the infrastructure to bookworm, testing usrmerge
variations broke again, and so is currently disabled... though I have
configured the paths_vary_due_to_usrmerge issue so that old known issues
are not automatically removed anymore.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1039064: binutils-msp430: file conflict with binutils-x86-64-linux-gnu

[Vagrant Cascadian]

On 2023-06-25, Ingo Saitz wrote:
> libdeb.so is both in binutils-x86-64-linux-gnu and binutils-msp430 in
> the same location. This was not the case in ~ti1, where libdeb.so was in
> /usr/lib/bfd-plugins/libdep.so. Thus the upgrade fails:
>
> Preparing to unpack .../binutils-msp430_2.24~ti2_amd64.deb ...
> Unpacking binutils-msp430 (2.24~ti2) over (2.24~ti1) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/binutils-msp430_2.24~ti2_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/bfd-plugins/libdep.so', which 
> is also in package binutils-x86-64-linux-gnu 2.40.50.20230622-1
> Errors were encountered while processing:
>  /var/cache/apt/archives/binutils-msp430_2.24~ti2_amd64.deb

Thanks for the report!

My bad, this points to some even deeper problems with the updates to
this package...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1037296: manderlbot: reproducible-builds: Different path to erl in /usr/bin/manderlbot

[Vagrant Cascadian]

Source: manderlbot
Severity: serious
Justification: TC resolution #994388
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The path to erl is embedded differently in /usr/bin/manderlbot depending
on if it was built on a usrmerge vs. non-usrmerge system:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/manderlbot.html

  ERL=/usr/bin/erl
  vs.
  ERL=/bin/erl

The attached patch fixes this by passing the path to ERL in a
debian/rules dh_auto_configure override. The path in /usr/bin is
compatible with both usrmerge and non-usrmerge systems.

According to my local tests, with this patch applied manderlbot should
build reproducibly on tests.reproducible-builds.org once it migrates to
testing! Unfortunately, there are other issues with build paths which
are only tested in unstable and experimental.

Thanks for maintaining manderlbot!

live well,
  vagrant
From 1d8e42b99a87810397cd1c50c36c79d545192575 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 10 Jun 2023 07:10:24 -0700
Subject: [PATCH] debian/rules: Specify path to "erl" binary in
 dh_auto_configure override.

Otherwise, the path to "erl" may be hardcoded to a path that only
works on a usrmerge system when built on a usrmerge system.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index ba8c906..b7c845a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,5 +27,8 @@ override_dh_gencontrol:
 	erlang-depends
 	dh_gencontrol
 
+override_dh_auto_configure:
+	dh_auto_configure -- ERL=/usr/bin/erl
+
 .PHONY: override_dh_auto_build override_dh_auto_install \
 	override_dh_gencontrol
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1037276: bglibs: reproducible-builds: Different path to perl in cli-generate

[Vagrant Cascadian]

Source: bglibs
Severity: serious
Justification: TC resolution #994388
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The path to perl is embedded differently in /usr/bin/cli-generate
depending on if it was built on a usrmerge vs. non-usrmerge system.

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/bglibs.html

  /usr/bin/cli-generate

  #!·/usr/bin/perl
  vs.
  #!·/bin/perl

The attached patch fixes this by explicitly specifying the path as
/usr/bin/perl instead of using 'which' to detect the path, which is
compatible with both usrmerge and non-usrmerge systems.


According to my local tests, with this patch applied bglibs should build
reproducibly on tests.reproducible-builds.org!


Thanks for maintaining bglibs!

live well,
  vagrant
From c62fcbde299245ffcd027fd524f2fd2419d874c4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jun 2023 18:44:06 -0700
Subject: Makefile: Ensure perl path is set to '/usr/bin/perl'.

Using 'which' to detect the path to perl may result in /bin/perl,
which is only typically available on usrmerge systems. /usr/bin/perl
is where perl has actually been installed for quite some time, and is
unlikely to change.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 2600365..8a87feb 100644
--- a/Makefile
+++ b/Makefile
@@ -864,8 +864,7 @@ path/mktemp.lo path/mktemp.o: ltcompile path/mktemp.c systime.h include/bglibs/p
 
 perl-head.pl: 
 	( set -e; PATH="/bin:/usr/bin:/usr/local/bin:$$PATH"; export PATH; \
-	  perl=`which perl`; \
-	  echo "#! $$perl"; \
+	  echo "#! /usr/bin/perl"; \
 	  echo "# WARNING: This file was auto-generated. Do not edit!"; \
 	  echo ) >perl-head.pl
 
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1034423: php8.2: reproducible-builds: Paths to sed in php-config8.2 and and phpize8.2

[Vagrant Cascadian]

Source: php8.2
Severity: serious
Justification: TC resolution #994388
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The paths to sed are embedded in two scripts shipped in /usr/bin:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/php8.2.html

  /usr/bin/php-config8.2

  SED="/bin/sed"
  vs.
  SED="/usr/bin/sed"

It appears this was attempted to be fixed in an earlier php package, but
the fix was either never effective, or has for some reason become
ineffective:

  https://bugs.debian.org/1015188

The attached patch fixes this by explicitly specifying the /usr/bin
path, which is compatible with both usrmerge and non-usrmerge systems.

Other approaches would be to adapt configure to be able to override the
autodetection of the path for SED, or perhaps ideal would be to specify
SED without any path, assuming it is always run in an environment where
PATH is set correctly.

Unfortunately, there are other outstanding issues and this patch is not
sufficient to make php8.2 reproducible, but it should reduce the
differences.

Thanks for maintaining php8.2!

live well,
  vagrant
From 830b885bf5495bd079bf698c7a3352ccf7a38633 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 13 Apr 2023 15:59:57 -0700
Subject: [PATCH] scripts/php*.in: Explicitly define the path to sed.

The full path is detected by configure, resulting in a different build
depending on if it is built on a usrmerge or non-usrmerge system.

Since usrmerge systems contain compatibility symlinks for the
non-usrmerge paths, use the non-usrmerge path which is compatible in
both systems.

https://tests.reproducible-builds.org/debian/issues/bookworm/paths_vary_due_to_usrmerge_issue.html
---
 scripts/php-config.in | 2 +-
 scripts/phpize.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/php-config.in b/scripts/php-config.in
index 45a07597..05307ee3 100644
--- a/scripts/php-config.in
+++ b/scripts/php-config.in
@@ -1,6 +1,6 @@
 #! /bin/sh
 
-SED="@SED@"
+SED="/bin/sed"
 prefix="@prefix@"
 datarootdir="@datarootdir@"
 exec_prefix="@exec_prefix@"
diff --git a/scripts/phpize.in b/scripts/phpize.in
index 0dcfe21d..0d71e795 100644
--- a/scripts/phpize.in
+++ b/scripts/phpize.in
@@ -7,7 +7,7 @@ exec_prefix="`eval echo @exec_prefix@`"
 phpdir="$prefix/lib/php/@DEBIAN_PHP_API@/build"
 includedir="$prefix/include/php/@DEBIAN_PHP_API@"
 builddir="`pwd`"
-SED="@SED@"
+SED="/bin/sed"
 
 libtool_version=$(dpkg-query -f'${Version}' -W libtool)
 aclocaldir="$prefix/share/aclocal"
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1033845: u-boot fails to boot on pinebook pro if installed on internal emmc

[Vagrant Cascadian]

Control: severity 1033845 important

Given that this only affects a single platform, and there are other
tested working boot options for this platform, I am downgrading the
severity to important.

On 2023-04-02, Wolf wrote:
> If the u-boot is installed on the internal emmc then u-boot is failing as
> follows:
> U-Boot SPL 2023.01+dfsg-2 (Jan 18 2023 - 01:57:16 +)
> Trying to boot from MMC1
> mmc fail to send stop cmd
> mmc_load_image_raw_sector: mmc block read error
> Trying to boot from MMC1
> mmc_load_image_raw_sector: mmc block read error
> Trying to boot from SPI
> Trying to boot from MMC2
> Card did not respond to voltage select! : -110
> spl: mmc init failed with error: -95
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###

So far I have only ever tested booting from microSD...

Did this work on previous versions?

Does it work on the version in experimental (currently 2023.04~rc5*)?


> The following patch in the configuration will fix that:
> pinebook-pro-rk3399_defconfig:
> --- pinebook-pro-rk3399_defconfig   2023-03-22 11:09:33.987508968 +0100
> +++ pinebook-pro-rk3399_defconfig   2023-03-22 12:56:41.773648426 +0100
> @@ -32,6 +32,7 @@ CONFIG_SPL_BSS_MAX_SIZE=0x2000
>  CONFIG_SPL_STACK=0x40
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
> +CONFIG_SPL_MTD_SUPPORT=y
>  CONFIG_SPL_SPI_LOAD=y
>  CONFIG_TPL=y
>  CONFIG_CMD_BOOTZ=y
> @@ -56,6 +57,8 @@ CONFIG_LED=y
>  CONFIG_LED_GPIO=y
>  CONFIG_MISC=y
>  CONFIG_ROCKCHIP_EFUSE=y
> +CONFIG_MMC_HS200_SUPPORT=y
> +CONFIG_SPL_MMC_HS200_SUPPORT=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_MMC_SDHCI=y

Would you consider submitting a patch upstream?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1033022: firefox-esr: does not display web pages

[Vagrant Cascadian]

On 2023-03-15, Vagrant Cascadian wrote:
> After upgrading to the latest firefox-esr, all web pages fail to display
> anything...
...
> Are there any unversioned or missing dependencies on something that
> should also come from sid?

Apparently, it needs libnss3 2:3.89-1 from sid to work properly...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1033022: firefox-esr: does not display web pages

[Vagrant Cascadian]

Package: firefox-esr
Version: 102.9.0esr-1
Severity: grave
X-Debbugs-Cc: vagr...@debian.org

After upgrading to the latest firefox-esr, all web pages fail to display
anything... except those in my pinned tabs, although those also fail to do
anything other than display presumably cached content? Closing and
restarting the browser did not help. Rebooting did not help.

Downgrading to the version from bookworm(102.8.0esr-1), and everything
works again!

FWIW, I am running with MOZ_ENABLE_WAYLAND=1 under sway.

Are there any unversioned or missing dependencies on something that
should also come from sid? I typically run bookworm, but occasionally
pull in specific packages from sid as desired. This usually has worked
fine over many years, so it is a bit surprising!

live well,
  vagrant


-- Package-specific info:


-- Addons package information


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental'), 
(1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-6-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 firefox-esr depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.6-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgtk-3-0   3.24.37-2
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.4-2
ii  libx11-xcb1  2:1.8.4-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.2-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec59  7:5.1.2-3

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.20.1-1
pn  pulseaudio 

-- no debconf information


signature.asc
Description: PGP signature

Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet

[Vagrant Cascadian]

On 2023-02-02, Vagrant Cascadian wrote:
> On 2023-02-01, Jérôme Charaoui wrote:
>> Perhaps an alternative would be to add "puppet-agent" as a build 
>> dependency, because that package will create a "puppet" user in the 
>> environment.

And for completeness, this also worked for me:

  sbuild --add-depends puppet-agent ...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet

[Vagrant Cascadian]

On 2023-02-01, Jérôme Charaoui wrote:
> I don't know how common that is in build environments, but it's not 
> something that I have or think I should have in my build (sbuild) or 
> test (autopkgtest) environments.

I was able to reproduce the issue with sbuild.

This appears to be because sbuild copies the host's /etc/passwd and
/etc/group into the chroot when it builds... and presumably the buildd
environment does this as well (and all DSA machines have the puppet user
available?)... and so the puppet user is in fact available in those
cases, but not others...

I was able to workaround the issue with:

  sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password 
puppet' ...

Is there an option in sbuild to not copy the passwd/group information
into the chroot? What are the implications of that?


> Is there some flag we could use to tell reproducible-builds to build 
> this package as a regular user instead of root?

It typically builds as two different users, pbuilder1 and pbuilder2, not
as root.


> If not I might have to patch the test suite to work around some of the 
> logic in there, which I'm not too excited about.
>
> Perhaps an alternative would be to add "puppet-agent" as a build 
> dependency, because that package will create a "puppet" user in the 
> environment.

That seems like a viable option, though obviously a bit ugly if that
package does a bunch of other things or has many other
dependencies. Would it make sense to have a package that just creates a
user and nothing else?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for dreamplug

[Vagrant Cascadian]

On 2022-12-29, Ian Campbell wrote:
> On Wed, 2022-12-28 at 16:30 -0800, Vagrant Cascadian wrote:
>> dreamplug
>
> booting u-boot and Debian both from external mmc
>
>  testing: 2022.04+dfsg-2+b1  "FDT and ATAGS support not compiled in" then 
> resets and loops doing that
> unstable: 2022.10+dfsg-2 ok
>  exp: 2023.01~rc4+dfsg-1 ok

Any chance you could test 2023.01+dfsg-1 and/or 2023.01+dfsg-2 on the
dreamplug? Someone had problems with sheevaplug, which I think is a
fairly similar platform.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)

[Vagrant Cascadian]

Control: found 1029066 230

On 2023-01-17, Gianfranco Costamagna wrote:
> Hello, your package FTBFS when internet is not available during control file 
> regeneration phase
...
> debian/tests/control.sh
> Generating the debian/tests/control file...
...
> ERROR: Could not find a version that satisfies the requirement setuptools 
> (from versions: none)
> ERROR: No matching distribution found for setuptools
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib/python3/dist-packages/pep517/meta.py", line 72, in load
>  path = Path(build_as_zip(builder))
>  ^
>File "/usr/lib/python3/dist-packages/pep517/meta.py", line 59, in 
> build_as_zip
>  builder(dest=out_dir)
>File "/usr/lib/python3/dist-packages/pep517/meta.py", line 53, in build
>  env.pip_install(system['requires'])
>File "/usr/lib/python3/dist-packages/pep517/envbuild.py", line 103, in 
> pip_install
>  check_call(
>File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
>  raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m', 'pip', 
> 'install', '--ignore-installed', '--prefix', 
> '/tmp/pep517-build-env-i1vz1wye', 'setuptools', 'wheel']' returned non-zero 
> exit status 1.
> Files debian/tests/control and debian/tests/control.tmp differ
>
> The generated control file differs from the actual one.
> A sourceful upload of this package is needed.
>
> Differences:
> --- debian/tests/control  2023-01-13 07:05:01.0 +
> +++ debian/tests/control.tmp  2023-01-17 02:06:59.340564039 +
> @@ -7,7 +7,7 @@
>   #   $ mv debian/tests/control.tmp debian/tests/control
>   
>   Tests: pytest-with-recommends
> -Depends: python3-all, diffoscope, black, python3-pytest, python3-h5py, file, 
> linux-image-amd64 [amd64] | linux-image-generic [amd64], abootimg, acl, 
> apksigcopier, apksigner, apktool [!ppc64el !s390x], binutils-multiarch, 
> bzip2, caca-utils, colord, coreboot-utils, db-util, default-jdk-headless | 
> default-jdk | java-sdk, device-tree-compiler, docx2txt, e2fsprogs, enjarify, 
> ffmpeg, fontforge-extras, fonttools, fp-utils [!ppc64el !s390x], genisoimage, 
> gettext, ghc, ghostscript, giflib-tools, gnumeric, gnupg, gnupg-utils, 
> hdf5-tools, html2text, imagemagick, jsbeautifier, libarchive-tools, 
> libxmlb-dev, llvm, lz4 | liblz4-tool, lzip, mono-utils, ocaml-nox, odt2txt, 
> oggvideotools [!s390x], openssh-client, openssl, pgpdump, poppler-utils, 
> procyon-decompiler, python3-pdfminer, r-base-core, rpm2cpio, sng, sqlite3, 
> squashfs-tools, tcpdump, u-boot-tools, unzip, wabt, xmlbeans, xxd, xz-utils, 
> zip, zstd, androguard, python3-argcomplete, python3-binwalk, 
> python3-defusedxml, python3-distro, python3-guestfs, python3-jsondiff, 
> python3-progressbar, python3-pypdf, python3-debian, python3-pyxattr, 
> python3-rpm, python3-tlsh
> +Depends: python3-all, diffoscope, black, python3-pytest, python3-h5py, file, 
> linux-image-amd64 [amd64] | linux-image-generic [amd64], abootimg, acl, 
> apksigcopier, apksigner, apktool [!ppc64el !s390x], binutils-multiarch, 
> bzip2, caca-utils, colord, coreboot-utils, db-util, default-jdk-headless | 
> default-jdk | java-sdk, device-tree-compiler, docx2txt, e2fsprogs, enjarify, 
> ffmpeg, fontforge-extras, fonttools, fp-utils [!ppc64el !s390x], genisoimage, 
> gettext, ghc, ghostscript, giflib-tools, gnumeric, gnupg, gnupg-utils, 
> hdf5-tools, html2text, imagemagick, jsbeautifier, libarchive-tools, 
> libxmlb-dev, llvm, lz4 | liblz4-tool, lzip, mono-utils, ocaml-nox, odt2txt, 
> oggvideotools [!s390x], openssh-client, openssl, pgpdump, poppler-utils, 
> procyon-decompiler, python3-pdfminer, r-base-core, rpm2cpio, sng, sqlite3, 
> squashfs-tools, tcpdump, u-boot-tools, unzip, wabt, xmlbeans, xxd, xz-utils, 
> zip, zstd,

Confirmed that it also affects the version in bookworm:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope.html

And according to test history, may go back to much earlier versions
(222+)... although there were some other possible FTBFS issues that may
have affected older versions, and I don't immediately see a way to look
at the logs from older versions.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on amlogic boards

[Vagrant Cascadian]

Control: severity 1027176 important

On 2023-01-05, Vagrant Cascadian wrote:
> Control: retitle 1027176 u-boot-amlogic: broken non-EFI boot on amlogic boards
...
> At this point, I am assuming that all the amlogic builds are affected,
> and worst case we include the "noefi" workaround for all boards.

I went ahead and uploaded 2023.01-rc4 to unstable with this as a
workaround.

> There has been some recent discussion in irc.libera.chat #u-boot and
> #linux-amlogic about this issue, so the possibility of an upstream fix
> coming is not impossible.

Hopefully we'll see a proper fix coming from upstream... :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-28, Rick Thomas wrote:
> A Cubox-i running Debian bullseye (11.6).  According to  versions> It has "u-boot-tools" (version 2021.01+dfsg-5) installed,
> but none of the u-boot- packages installed.
>
> If I reboot it and watch the serial console, I see it showing "U-boot
> 2021.01-dfsg-5" so that version must have gotten into the firmware
> somehow without telling Linux about it... 

Installing the packge does not install u-boot to the boot media, it is a
manual process, as it can be board-specific.


> Other info that might be helpful that shows with the reboot is
> CPU: Freescale i.MX6Q rev 1.3
> Board: MX6 Cubox-i

For Cubox-i install u-boot-imx and see
/usr/share/doc/u-boot-imx/README.Debian for instructions on how to
actually install the boot firmware onto microSD.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on amlogic boards

[Vagrant Cascadian]

Control: retitle 1027176 u-boot-amlogic: broken non-EFI boot on amlogic boards

On 2023-01-05, Frédéric Danis wrote:
> On 03/01/2023 18:55, Vagrant Cascadian wrote:
>> Sounds like the bug *is* reproducible with unstable and experiemental
>> versions, from reading the logs; looks like the same issue with
>> odroid-c2.
>>
>> Could you try building a "noefi" variant, like done with odroid-c2, and
>> test for the lepotato (libretech-cc?):
>>
>>
>> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d
>
> The "noefi" variant works fine for unstable (2022.10+dfsg-2) and 
> experimental (2023.01~rc4+dfsg-1) versions.
> I create a merge request for it: 
> https://salsa.debian.org/debian/u-boot/-/merge_requests/28

Thanks, merged!

>> Could you also test EFI booting with the versions from unstable and
>> experimental to see if they can load a kernel? If EFI does work, that
>> justifies building two variants with and without EFI... it is a bit ugly
>> to produce two variants, but it's the easiest known workaround for
>> now...
>
> I'm able to boot the debian-installer mini.iso and get the first install 
> menu with unstable and experimental u-boot.

Thanks for the testing!

At this point, I am assuming that all the amlogic builds are affected,
and worst case we include the "noefi" workaround for all boards.

There has been some recent discussion in irc.libera.chat #u-boot and
#linux-amlogic about this issue, so the possibility of an upstream fix
coming is not impossible.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for rock-pi-4-rk3399

[Vagrant Cascadian]

On 2023-01-05, Christopher Obbard wrote:
> On Thu, 2023-01-05 at 13:21 -0300, Walter Lozano wrote:
>> 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.

I would definitely be amenable to such a patch, although probably best
in a separate bug report and/or merge request. Could even use some
wildcards, if appropriate.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for Mini-X

[Vagrant Cascadian]

On 2023-01-04, Jochen Sprickerhof wrote:
> * Vagrant Cascadian  [2022-12-28 16:56]:
>>> 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.
>>
>>Mini-X
>
> Works fine with unstable, I've updated the wiki page.

Thanks! Any chance you could also test 2023.01-rc* from experimental? At
this point 2023.01 is the version I am most likely to try to push to
bookworm.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: please test u-boot for roc-pc-rk3399 rock-pi-e-rk3328

[Vagrant Cascadian]

On 2023-01-05, Christopher Obbard wrote:
> 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-4b-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable
>   - SD boot: works
>   - MAC address: correctly derived from serial number

Thanks for the tests!

> @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 ?

2023.01 should be released in a few days and I hope to land that in
bookworm. That avoids the need for this and a couple other backported
patches.

I am even tempted to just push 2023.01-rc4 to unstable right now, given
the testing has fared at least as good as 2022.10...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-03, Vagrant Cascadian wrote:
> On 2023-01-03, Vagrant Cascadian wrote:
>> On 2023-01-02, Vagrant Cascadian wrote:
>>> On 2023-01-02, Vagrant Cascadian wrote:
>>>> On 2022-12-28, Vagrant Cascadian wrote:
>>>>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
>>>>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
>>>>> commit triggering the issue has been identified as:
>>>>>
>>>>>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>>>>>   efi_loader: disk: a helper function to create efi_disk objects from
>>>>>   udevice
>>>>>
>>>>> Workarounds I've heard are to disable EFI support for that board
>>> ...
>>>> Obviously, it breaks EFI booting...
>>>>
>>>> Worst case, I suppose we could create two variants, one with EFI, one
>>>> without...
>>>
>>> I have pushed a patch to git implementing an odroid-c2-noefi variant:
>>>
>>>   
>>> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d
>>>
>>> This would not close the bug, but at least downgrade the severity...
>>
>> I can confirm that 2023.01-rc4+dfsg-1 does boot successfully with EFI on
>> the odroid-c2, so ... the two variant solution is a viable one if a
>> proper fix cannot be figured out in time for bookworm.
>
> From irc.libera.chat #u-boot:
>
>  < xypron> Tartarus: Loading Ramdisk to 7a896000, end 7bf3eb78
>overwrites internal memory structures of the EFI subsystem
>which leads to the crash on the Odroid C2. Why do we copy
>initrd to high memory at all?
> 
>  < xypron> vagrantc: Tartarus: setenv initrd_high 0x;
>setenv fdt_high 0x solves the problem on the
>Odroid C2
>
> I can confirm this works around the issue, although it may also cause
> other problems and should not be the default...

Another possible workaround...

  < Tartarus> A less dangerous work-around would be to us bootm_low or
  bootm_size (See
  https://u-boot.readthedocs.io/en/latest/usage/environment.html)
  to limit where relocations can be

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-03, Vagrant Cascadian wrote:
> On 2023-01-02, Vagrant Cascadian wrote:
>> On 2023-01-02, Vagrant Cascadian wrote:
>>> On 2022-12-28, Vagrant Cascadian wrote:
>>>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
>>>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
>>>> commit triggering the issue has been identified as:
>>>>
>>>>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>>>>   efi_loader: disk: a helper function to create efi_disk objects from
>>>>   udevice
>>>>
>>>> Workarounds I've heard are to disable EFI support for that board
>> ...
>>> Obviously, it breaks EFI booting...
>>>
>>> Worst case, I suppose we could create two variants, one with EFI, one
>>> without...
>>
>> I have pushed a patch to git implementing an odroid-c2-noefi variant:
>>
>>   
>> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d
>>
>> This would not close the bug, but at least downgrade the severity...
>
> I can confirm that 2023.01-rc4+dfsg-1 does boot successfully with EFI on
> the odroid-c2, so ... the two variant solution is a viable one if a
> proper fix cannot be figured out in time for bookworm.

From irc.libera.chat #u-boot:

 < xypron> Tartarus: Loading Ramdisk to 7a896000, end 7bf3eb78
   overwrites internal memory structures of the EFI subsystem
   which leads to the crash on the Odroid C2. Why do we copy
   initrd to high memory at all?

 < xypron> vagrantc: Tartarus: setenv initrd_high 0x;
   setenv fdt_high 0x solves the problem on the
   Odroid C2

I can confirm this works around the issue, although it may also cause
other problems and should not be the default...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-03, Frédéric Danis wrote:
> On 03/01/2023 18:55, Vagrant Cascadian wrote:
>> On 2023-01-03, Frédéric Danis wrote:
>>> Afaiu, the bug is not reproducible with unstable and experimental
>>> versions, but boot crash before starting the kernel, see
>>> lepotato-unstable.txt and lepotato-experimental.txt.
>> Sounds like the bug *is* reproducible with unstable and experiemental
>> versions, from reading the logs; looks like the same issue with
>> odroid-c2.
>>
>> Could you try building a "noefi" variant, like done with odroid-c2, and
>> test for the lepotato (libretech-cc?):
>>
>>
>> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d
>
> I will try to build and test this
>
>> Could you also test EFI booting with the versions from unstable and
>> experimental to see if they can load a kernel? If EFI does work, that
>> justifies building two variants with and without EFI... it is a bit ugly
>> to produce two variants, but it's the easiest known workaround for
>> now...
>
> I will need your help on this as I don't know how to test EFI boot, for 
> me EFI was specific to Intel platforms.
> Can you point me to a doc explaining how to do this on LePotato/Arm board?

What I did for the odroid-c2 was download the debian-installer mini.iso:

  https://d-i.debian.org/daily-images/arm64/daily/netboot/

And dump it onto a USB stick. Then at boot, I interrupted the boot
process, and at the u-boot prompt:

  setenv boot_targets usb0
  boot

This of course presumes usb works for your platform.

You might be able to do a dance with microSD or whatever by booting from
microSD, yanking the microSD card, inserting a microSD card with the
mini.iso installed, rescanning the mmc bus, etc. but that is obviously a
lot tricker!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-02, Vagrant Cascadian wrote:
> On 2023-01-02, Vagrant Cascadian wrote:
>> On 2022-12-28, Vagrant Cascadian wrote:
>>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
>>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
>>> commit triggering the issue has been identified as:
>>>
>>>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>>>   efi_loader: disk: a helper function to create efi_disk objects from
>>>   udevice
>>>
>>> Workarounds I've heard are to disable EFI support for that board
> ...
>> Obviously, it breaks EFI booting...
>>
>> Worst case, I suppose we could create two variants, one with EFI, one
>> without...
>
> I have pushed a patch to git implementing an odroid-c2-noefi variant:
>
>   
> https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d
>
> This would not close the bug, but at least downgrade the severity...

I can confirm that 2023.01-rc4+dfsg-1 does boot successfully with EFI on
the odroid-c2, so ... the two variant solution is a viable one if a
proper fix cannot be figured out in time for bookworm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-03, Frédéric Danis wrote:
> On 29/12/2022 00:07, Vagrant Cascadian wrote:
>> On 2022-12-28, Vagrant Cascadian wrote:
>>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
>>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
>>> commit triggering the issue has been identified as:
>>>
>>>a9bf024b2933bba0e23038892970a18b72dfaeb4
>>>efi_loader: disk: a helper function to create efi_disk objects from
>>>udevice
>>>
>>> Workarounds I've heard are to disable EFI support for that board, or to
>>> boot using EFI rather than boot scripts or syslinux/extlinux style
>>> menus.
>>>
>>> I will also want to get confirmation if other amlogic boards are
>>> affected...
>> The currently supported amlogic platforms are:
>>
>># Neil Armstrong 
>>u-boot-amlogic_platforms += khadas-vim
>>
>># Neil Armstrong 
>>u-boot-amlogic_platforms += khadas-vim2
>>
>># Frederic Danis 
>>u-boot-amlogic_platforms += libretech-cc
>>
>># Neil Armstrong 
>>u-boot-amlogic_platforms += nanopi-k2
>>
>># Vagrant Cascadian 
>>u-boot-amlogic_platforms += odroid-c2
>>
>># Reco 
>>u-boot-amlogic_platforms += odroid-n2
>>
>> Please test if the current versions from Debian unstable (2022.10*) and
>> experimental (2023.01-rc*) are affected by this issue... and if there
>> are other issues for Debian bookworm/testing (2022.04*).
>>
>> This is part of what has been blocking u-boot from migrating to testing.
>>
>>
>> I do not see (m)any records of tests for most of these platforms at:
>>
>>https://wiki.debian.org/U-boot/Status
>>
>>
>> live well,
>>vagrant
>
> u-boot bookworm version works fine with LePotato board (libretech-cc), 
> see attached lepotato-bookworm.txt.

Thanks!

> Afaiu, the bug is not reproducible with unstable and experimental 
> versions, but boot crash before starting the kernel, see 
> lepotato-unstable.txt and lepotato-experimental.txt.

Sounds like the bug *is* reproducible with unstable and experiemental
versions, from reading the logs; looks like the same issue with
odroid-c2.

Could you try building a "noefi" variant, like done with odroid-c2, and
test for the lepotato (libretech-cc?):

  
https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d



Could you also test EFI booting with the versions from unstable and
experimental to see if they can load a kernel? If EFI does work, that
justifies building two variants with and without EFI... it is a bit ugly
to produce two variants, but it's the easiest known workaround for
now...


Will try to test EFI on the odroid-c2 shortly...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-02, Vagrant Cascadian wrote:
> On 2022-12-28, Vagrant Cascadian wrote:
>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
>> commit triggering the issue has been identified as:
>>
>>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>>   efi_loader: disk: a helper function to create efi_disk objects from
>>   udevice
>>
>> Workarounds I've heard are to disable EFI support for that board
...
> Obviously, it breaks EFI booting...
>
> Worst case, I suppose we could create two variants, one with EFI, one
> without...

I have pushed a patch to git implementing an odroid-c2-noefi variant:

  
https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d

This would not close the bug, but at least downgrade the severity...


I still do not have confirmation if the other amlogic boards are
similarly affected.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2022-12-28, Vagrant Cascadian wrote:
> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
> commit triggering the issue has been identified as:
>
>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>   efi_loader: disk: a helper function to create efi_disk objects from
>   udevice
>
> Workarounds I've heard are to disable EFI support for that board, or to
> boot using EFI rather than boot scripts or syslinux/extlinux style
> menus.

Well, this patch applied to 2022.10+dfsg-2 or 2023.01~rc4+dfsg-1 is
enough to get it booting on odroid-c2 with syslinux/extlinux style menus
and boot scripts:

diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index a4c4fc7906..281d5e0014 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -67,3 +67,4 @@ CONFIG_BMP_16BPP=y
 CONFIG_BMP_24BPP=y
 CONFIG_BMP_32BPP=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_LOADER is not set

Obviously, it breaks EFI booting...

Worst case, I suppose we could create two variants, one with EFI, one
without...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027297: u-boot: guruplug/sheevaplug: FDT and ATAGS support not compiled in

[Vagrant Cascadian]

Package: u-boot
Version: 2022.04+dfsg-2
Severity: serious
Control: fixed -1 2022.10+dfsg-2
X-Debbugs-Cc: vagr...@debian.org, m...@drkrebs.de, t...@cyrius.com, 
i...@debian.org

At least two people have reported the same issue on sheevaplug and
guruplug failing to boot with a message "FDT and ATAGS support not
compiled in".

I suspect this was fixed in 2022.10-rc5 upstream with this commit:

  
https://source.denx.de/u-boot/u-boot/-/commit/a8a0c55f9d1cd0f4618288b25f63857373015391

  arm: kirkwood: Add CONFIG_SUPPORT_PASSING_ATAGS

Both tests confirm it working again with u-boot 2022.10+dfsg-2 and
2023.01~rc4+dfsg-1 from Debian.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Help with testing u-boot!

[Vagrant Cascadian]

On 2022-12-29, Diederik de Haas wrote:
> On Thursday, 29 December 2022 00:21:05 CET Vagrant Cascadian wrote:
>> debian stable (2021.01*), testing (2022.04*), unstable (2022.10*)
>> and experimental (2023.01-rc*)
>>
>> # arm64
>> ...
>> rock64-rk3328
>
> I don't recall ever having issues with u-boot on my Rock64's, so for me 
> 2022.04 - 2022.10 surely work. I'll try the experimental version soon.

I have been testing that one, but thanks for the extra testing!


> I generate my own images for Rock64 and that uses 'dd ... seek=' of 
> idbloader.img and u-boot.itb from the u-boot-rockchip package.
> I have been doing that since 2021-03, so it's very likely that I haven't seen 
> an issue since then.

u-boot-rockchip also includes a u-boot-install-rockchip script which
might simplify the process for you. :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for nanopi_neo

[Vagrant Cascadian]

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.

nanopi_neo

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for orangepi_zero

[Vagrant Cascadian]

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.

orangepi_zero

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for nanopi_neo_air

[Vagrant Cascadian]

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.

nanopi_neo_air

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for Linksprite_pcDuino3

[Vagrant Cascadian]

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.

Linksprite_pcDuino3

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for Mini-X

[Vagrant Cascadian]

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.

Mini-X

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for Linksprite_pcDuino

[Vagrant Cascadian]

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.

Linksprite_pcDuino

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for Bananapi_M2_Ultra Sinovoip_BPI_M3

[Vagrant Cascadian]

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.

Bananapi_M2_Ultra
Sinovoip_BPI_M3

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for A20-OLinuXino_MICRO-eMMC

[Vagrant Cascadian]

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.

A20-OLinuXino_MICRO-eMMC

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for A20-OLinuXino_MICRO

[Vagrant Cascadian]

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.

A20-OLinuXino_MICRO

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for A20-OLinuXino-Lime2-eMMC

[Vagrant Cascadian]

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.

A20-OLinuXino-Lime2-eMMC

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for A20-OLinuXino-Lime2 A20-Olimex-SOM-EVB Bananapro Cubieboard2 Cubietruck

[Vagrant Cascadian]

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.

A20-OLinuXino-Lime2
A20-Olimex-SOM-EVB
Bananapro
Cubieboard2
Cubietruck

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for A10s-OLinuXino-M

[Vagrant Cascadian]

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.

A10s-OLinuXino-M

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for A10-OLinuXino-Lime A20-OLinuXino-Lime

[Vagrant Cascadian]

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.

A10-OLinuXino-Lime
A20-OLinuXino-Lime

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for am335x_boneblack am335x_evm

[Vagrant Cascadian]

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.

am335x_boneblack
am335x_evm

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for udoo

[Vagrant Cascadian]

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.

udoo

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for nitrogen6q sifive_unleashed

[Vagrant Cascadian]

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.

nitrogen6q
sifive_unleashed

I'm able to test sifive_unmatched myself, but more people testing the
better.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for mx6cuboxi

[Vagrant Cascadian]

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.

mx6cuboxi

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for mx6cuboxi

[Vagrant Cascadian]

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.

mx6cuboxi

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for mx53loco wandboard igep00x0 omap3_beagle omap4_panda Cubietruck

[Vagrant Cascadian]

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.

mx53loco
wandboard
igep00x0
omap3_beagle
omap4_panda
Cubietruck

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for dh_imx6

[Vagrant Cascadian]

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.

dh_imx6

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for colibri_imx6

[Vagrant Cascadian]

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.

colibri_imx6

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for odroid

[Vagrant Cascadian]

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.

odroid

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for rpi_0_w

[Vagrant Cascadian]

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.

rpi_0_w

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for sheevaplug mx6cuboxi

[Vagrant Cascadian]

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.

sheevaplug
mx6cuboxi

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for guruplug sheevaplug

[Vagrant Cascadian]

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.

guruplug
sheevaplug

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for dreamplug jetson-tk1 Bananapi Cubieboard2 Cubietruck

[Vagrant Cascadian]

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.

dreamplug
jetson-tk1
Bananapi
Cubieboard2 
Cubietruck

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for teres_i

[Vagrant Cascadian]

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.

teres_i

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for sopine_baseboard

[Vagrant Cascadian]

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.

sopine_baseboard

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for orangepi_one_plus

[Vagrant Cascadian]

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.

orangepi_one_plus

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for pinephone

[Vagrant Cascadian]

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.

pinephone

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for pine64-lts

[Vagrant Cascadian]

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.

pine64-lts

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for orangepi_one_plus

[Vagrant Cascadian]

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.

orangepi_one_plus

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for nanopi_neo2

[Vagrant Cascadian]

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.

nanopi_neo2

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for a64-olinuxino-emmc

[Vagrant Cascadian]

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.

a64-olinuxino-emmc

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for a64-olinuxino

[Vagrant Cascadian]

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.

a64-olinuxino

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for rpi_4 rpi_4_32b

[Vagrant Cascadian]

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.

rpi_4
rpi_4_32b

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for rpi_4 bananapi_m2_berry rpi_4_32b

[Vagrant Cascadian]

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.

rpi_4
bananapi_m2_berry
rpi_4_32b


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for rpi_3 rpi_3_32b

[Vagrant Cascadian]

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.

rpi_3
rpi_3_32b

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for mx6qsabrelite

[Vagrant Cascadian]

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.

mx6qsabrelite


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for pinephone pinetab stm32mp157c-dk2

[Vagrant Cascadian]

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.

pinephone
pinetab
stm32mp157c-dk2

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for orangepi_zero_plus2

[Vagrant Cascadian]

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.

orangepi_zero_plus2


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test with helping rpi_arm64

[Vagrant Cascadian]

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.

rpi_arm64


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for rock-pi-4-rk3399

[Vagrant Cascadian]

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


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: please test u-boot for roc-pc-rk3399 rock-pi-e-rk3328

[Vagrant Cascadian]

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


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for nanopc-t4-rk3399 nanopi-neo4-rk3399 nanopi_neo_plus2

[Vagrant Cascadian]

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.

nanopc-t4-rk3399
nanopi-neo4-rk3399
nanopi_neo_plus2

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Please test u-boot for dragonboard410c and dragonboard820c

[Vagrant Cascadian]

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.
  
dragonboard410c
dragonboard820c

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: Help with testing u-boot!

[Vagrant Cascadian]

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.

# arm64
khadas-vim
khadas-vim2
libretech-cc
nanopi-k2
odroid-c2
odroid-n2
mvebu_espressobin-88f3720
dragonboard410c
dragonboard820c
firefly-rk3399
nanopc-t4-rk3399
nanopi-neo4-rk3399
pinebook-pro-rk3399
puma-rk3399
roc-pc-rk3399
rock-pi-4-rk3399
rock-pi-e-rk3328
rock64-rk3328
rockpro64-rk3399
rpi_3
rpi_4
rpi_arm64
a64-olinuxino
a64-olinuxino-emmc
nanopi_neo2
nanopi_neo_plus2
orangepi_one_plus
orangepi_zero_plus2
pine64-lts
pine64_plus
pinebook
pinephone
pinetab
sopine_baseboard
teres_i
p2371-2180

# armel
dockstar
dreamplug
guruplug
sheevaplug
rpi
rpi_0_w

# armhf
arndale
odroid
odroid-xu3
colibri_imx6
dh_imx6
mx53loco
mx6cuboxi
mx6qsabrelite
nitrogen6q
novena
novena-rawsd
udoo
usbarmory
wandboard
am335x_boneblack
am335x_evm
am57xx_evm
dra7xx_evm
igep00x0
nokia_rx51
omap3_beagle
omap4_panda
firefly-rk3288
rpi_2
rpi_3_32b
rpi_4_32b
stm32mp157c-dk2
A10-OLinuXino-Lime
A10s-OLinuXino-M
A20-OLinuXino-Lime
A20-OLinuXino-Lime2
A20-OLinuXino-Lime2-eMMC
A20-OLinuXino_MICRO
A20-OLinuXino_MICRO-eMMC
A20-Olimex-SOM-EVB
Bananapi
Bananapi_M2_Ultra
Bananapro
CHIP
Cubieboard
Cubieboard2
Cubieboard4
Cubietruck
Cubietruck_plus
Lamobo_R1
Linksprite_pcDuino
Linksprite_pcDuino3
Mini-X
Sinovoip_BPI_M3
bananapi_m2_berry
nanopi_neo
nanopi_neo_air
orangepi_plus
orangepi_zero
jetson-tk1


Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1011863: marked as pending in guix

[Vagrant Cascadian]

Control: tag -1 pending

Hello,

Bug #1011863 in guix reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/guix/-/commit/6b1c4a4ff194a9e225c0629a87e7d3a218a8b2ce


debian/patches: Remove expiration dates on openpgp keys used in test suite.
(Closes: #1011863)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1011863

Bug#1016963: u-boot: delay migration to testing to test more platforms

[Vagrant Cascadian]

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
>
> Well, this turned out to be pretty troublesome. The pinebook-pro-rk3399
> u-boot boots, but causes issues loading the rootfs from nvme or microsd.

Pushed a fix for the pinebook-pro-rk3399 to the debian/sid branch by
pulling a patch from upstream:

  
https://salsa.debian.org/debian/u-boot/-/commit/2557bb1b4be611fb1d8f96d7de79914ca21fa2b6

This fix landed in upstream in 2023.01-rc4.


> the odroid-c2 crashes as soon as it tries to switch to the kernel.

Still need to dig out the odroid-c2 and possibly troubleshoot if there
is something in the flashing process that has changed, or ... bisect
upstream git.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1005413: NMU fixing FTBFS and reproducible builds issues

[Vagrant Cascadian]

>first_minor = cloop_num;
  clo->clo_disk->fops = &clo_fops;
- clo->clo_disk->queue = clo->clo_queue;
  clo->clo_disk->private_data = clo;
  sprintf(clo->clo_disk->disk_name, "%s%d", cloop_name, cloop_num);
- add_disk(clo->clo_disk);
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+ error = add_disk(clo->clo_disk);
+ if (error)
+  goto error_out_free_disk;
+#endif
  return 0;
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+error_out_free_disk:
+ blk_cleanup_disk(clo->clo_disk);
+#endif
 error_out_free_queue:
+#if LINUX_VERSION_CODE < KERNEL_VERSION(5,15,0)
  blk_cleanup_queue(clo->clo_queue);
 error_out_free_tags:
+#endif
  blk_mq_free_tag_set(&clo->tag_set);
 error_out_free_clo:
  cloop_free(clo, sizeof(struct cloop_device));
 error_out:
- return -ENOMEM;
+ return error;
 }
 
 static void cloop_dealloc(int cloop_num)
@@ -1178,9 +1191,13 @@
  struct cloop_device *clo = cloop_dev[cloop_num];
  if(clo == NULL) return;
  del_gendisk(clo->clo_disk);
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,15,0)
+ blk_cleanup_disk(clo->clo_disk);
+#else
  blk_cleanup_queue(clo->clo_queue);
- blk_mq_free_tag_set(&clo->tag_set);
  put_disk(clo->clo_disk);
+#endif
+ blk_mq_free_tag_set(&clo->tag_set);
  cloop_free(clo, sizeof(struct cloop_device));
  cloop_dev[cloop_num] = NULL;
 }
@@ -1269,8 +1286,3 @@
 /* The cloop init and exit function registration (especially needed for Kernel 
2.6) */
 module_init(cloop_init);
 module_exit(cloop_exit);
-
-#include 
-#include 
-
-MODULE_INFO(vermagic, VERMAGIC_STRING);
diff -Nru cloop-3.14.1.3/debian/changelog cloop-3.14.1.3+nmu1/debian/changelog
--- cloop-3.14.1.3/debian/changelog 2020-04-19 01:18:13.0 -0700
+++ cloop-3.14.1.3+nmu1/debian/changelog2022-12-22 12:41:49.0 
-0800
@@ -1,3 +1,30 @@
+cloop (3.14.1.3+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Ben Hutchings ]
+  * Fix FTBFS with gcc 11 (Closes: #1005413):
+- Remove exception specifications
+  * Fix module build for recent kernel versions (Closes: #1005414):
+- Stop generating module vermagic in cloop.c. This has always been handled
+  by modpost and doing it here now results in build failure.
+- Avoid using inode::i_bdev, which was removed in Linux 5.11.
+- Use set_disk_ro() instead of set_device_ro(). The latter was not meant to
+  be used by device drivers and was removed in Linux 5.11.
+- Use blk_{mq_alloc,cleanup}_disk() instead of separate queue and disk
+  allocation and cleanup on Linux 5.15+, since alloc_disk() was removed.
+- Handle potential failure of add_disk() on Linux 5.15+.
+- Use kernel_read() instead of vfs_read() and set_fs(). set_fs() is no
+  longer defined on some architectures, and kernel_read() has had large
+  file support since Linux 2.6.31.
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Build tarball reproducibly, using consistent time, uid,
+gid and sort order. Thanks to Dhole for the initial patch.
+(Closes: #787996)
+
+ -- Vagrant Cascadian   Thu, 22 Dec 2022 
12:41:49 -0800
+
 cloop (3.14.1.3) unstable; urgency=medium
 
   * Upgrading to more recent debhelper and latest policy standards
diff -Nru cloop-3.14.1.3/debian/rules cloop-3.14.1.3+nmu1/debian/rules
--- cloop-3.14.1.3/debian/rules 2020-04-19 01:18:13.0 -0700
+++ cloop-3.14.1.3+nmu1/debian/rules2022-12-22 12:41:49.0 -0800
@@ -28,4 +28,4 @@
cp Makefile *.c *.h README ChangeLog $(XDIR)
cd debian && install rules.m-a ../$(XDIR)/debian/rules && cp -r po 
compat control* copyright *_KVERS_* README.Debian changelog ../$(XDIR)/debian
dh_fixperms -i -Xrules
-   cd debian/cloop-src/usr/src && XZ_OPT=-9 tar --xz -c -f cloop.tar.xz 
modules && rm -rf modules
+   cd debian/cloop-src/usr/src && XZ_OPT=-9 tar --xz --sort=name 
--mtime=@$(SOURCE_DATE_EPOCH) --owner=0 --group=0 --numeric-owner  -c -f 
cloop.tar.xz modules && rm -rf modules


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025954: would you like to test new patch?

[Vagrant Cascadian]

On 2022-12-13, 张 宁 wrote:
> I understand why it fail to boot.
>
> static int parse_label(char **c, struct pxe_menu *cfg)
> it failed to parse "kalsrseed", and move to uplayer, and uplayer still don't 
> know how to handle it.
> and affected "append"

Thanks for looking into it!

> I don't have old version u-boot, thus can't test it out.
>
> I have a new patch, would you like to have a try.
> diff --git a/u-boot-update b/u-boot-update
> index 90c4087..ebcf8cf 100755
> --- a/u-boot-update
> +++ b/u-boot-update
> @@ -257,6 +257,7 @@ label l${_NUMBER}
>   ${_FDT}
>   ${_FDTOVERLAYS}
>   append ${U_BOOT_ROOT} ${U_BOOT_PARAMETERS}"
> + kalsrseed
>  
>   fi

Yeah, this is basically the same as what Arnaud Ferraris proposed.

I worry a bit that this is just a workaround a deeper problem... though
maybe it is the best we have.

For now I uploaded a version that reverted the kaslrseed support and
will test more thoroughly before re-uploading with the kaslrseed support
enabled again.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025954: marked as pending in u-boot-menu

[Vagrant Cascadian]

Control: tag -1 pending

Hello,

Bug #1025954 in u-boot-menu reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/u-boot-menu/-/commit/ce91ec282087632dea7b1d5be444bf9aac3cfd6f


Revert "add kalsrseed support" (Closes: #1025954)

This reverts commit ff483d04dc558e7339f7904205564dcfd889db79.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1025954

Bug#1020087: guile-ssh: FTBFS: dh_auto_test: error: cd debian/build/guile-3.0 && make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

[Vagrant Cascadian]

Control: forwarded 1020087 https://github.com/artyom-poptsov/guile-ssh/issues/34

On 2022-09-18, Lucas Nussbaum wrote:
>> make[5]: Entering directory '/<>/debian/build/guile-3.0/tests'
>> PASS: log.scm
>> FAIL: server.scm
>> PASS: session.scm
>> FAIL: client-server.scm
>> PASS: popen.scm
>> PASS: shell.scm
>> PASS: server-client.scm
>> PASS: sssh-ssshd.scm
>> FAIL: key.scm
>> PASS: tunnel.scm
>> PASS: dist.scm
>> 
>>Guile-SSH 0.13.1: tests/test-suite.log
>> 
>> 
>> # TOTAL: 11
>> # PASS:  8
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  3
>> # XPASS: 0
>> # ERROR: 0

I believe this is due to the new libssh 0.10.x version introduced middle
of september 2022 and compatibility issues in guile-ssh's test suite.

I've confirmed the issue on guile-ssh 0.13.x, 0.15.x and 0.16.x locally,
and the reproducible builds tests also confirm this rough timing:

  https://tests.reproducible-builds.org/debian/history/amd64/guile-ssh.html

Forwarded the bug upstream.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

[Vagrant Cascadian]

On 2022-10-11, Philip Rinn wrote:
> OK, I used a custom bootstrap script now and that works:

For clarity, sounds like you used u-boot-menu (at my suggestion), which
does not use boot scripts...

> U-Boot 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +) Allwinner Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Olimex A64-Olinuxino-eMMC
> DRAM:  2 GiB
> Core:  74 devices, 20 uclasses, devicetree: separate
> WDT:   Not starting watchdog@1c20ca0
> MMC:   mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
> Loading Environment from FAT... Unable to use mmc 0:1...
> In:serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@1c3
> starting USB...
> Bus usb@1c1a000: USB EHCI 1.00
> Bus usb@1c1a400: USB OHCI 1.0
> Bus usb@1c1b000: USB EHCI 1.00
> Bus usb@1c1b400: USB OHCI 1.0
> scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
> scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
> scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
> scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found /boot/extlinux/extlinux.conf
> Retrieving file: /boot/extlinux/extlinux.conf
> U-Boot menu
> 1:  Debian GNU/Linux bookworm/sid 5.19.0-2-arm64
> 2:  Debian GNU/Linux bookworm/sid 5.19.0-2-arm64 (rescue target)
> Enter choice: 1:Debian GNU/Linux bookworm/sid 5.19.0-2-arm64
> Retrieving file: /boot/initrd.img-5.19.0-2-arm64
> Retrieving file: /boot/vmlinuz-5.19.0-2-arm64
> append: root=/dev/mmcblk0p1 ro quiet
> Retrieving file: 
> /usr/lib/linux-image-5.19.0-2-arm64/allwinner/sun50i-a64-olinuxino-emmc.dtb
> Moving Image from 0x4008 to 0x4020, end=4200
> ## Flattened Device Tree blob at 4fa0
> Booting using the fdt blob at 0x4fa0
> Loading Ramdisk to 48196000, end 49d7 ... OK
> Loading Device Tree to 4818b000, end 48195370 ... OK
>
> Starting kernel ...
>
> [3.943010] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 40
...
> [5.065265] sunxi-mmc 1c1.mmc: Error applying setting, reverse things 
> back
> [5.236700] sunxi-mmc 1c11000.mmc: data error, sending stop command
> [6.244813] sunxi-mmc 1c11000.mmc: send stop command failed
> [   11.139614] lima 1c4.gpu: error -ENODEV: dev_pm_opp_set_regulators: no 
> regulator (mali) found
>
> Debian GNU/Linux bookworm/sid debian ttyS0
>
> debian login:

Ok, some success!


> I did use
>
> TARGET=/usr/lib/u-boot/a64-olinuxino-emmc/ u-boot-install-sunxi64 ${SDCARD}

Why did you have to specify TARGET? Was it not able to detect the
correct board? Or were you running u-boot-install-sunxi64 that from
another system?


That said, if u-boot-menu's generated /boot/extlinux/extlinux.conf is
correctly parsed by u-boot, I'm at a loss why flash-kernel's generated
boot script wouldn't work... (they both basically end load the
kernel/initrd/dtb into ram and call "booti $kernel_addr_r
$ramdisk_addr_r $fdt_addr_r"). I've seen this before, and don't recall
coming up with a resolution.

Wild guess; maybe the flash-kernel boot.scr gets the wrong console
settings (e.g. serial vs. hdmi or whatnot), while u-boot-menu just uses
the default console specified in the .dtb?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: u-boot: delay migration to testing to test more platforms

[Vagrant Cascadian]

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

Well, this turned out to be pretty troublesome. The pinebook-pro-rk3399
u-boot boots, but causes issues loading the rootfs from nvme or microsd.

the odroid-c2 crashes as soon as it tries to switch to the kernel.

So, problems on two out of four platforms that I've tried so far.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016963: u-boot: delay migration to testing to test more platforms

[Vagrant Cascadian]

Source: u-boot
Version: 2022.07+dfsg-1
Severity: serious
X-Debbugs-Cc: Vagrant Cascadian 

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

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012996: mes: ftbfs with GCC-12

[Vagrant Cascadian]

Control: severity 1012996 important

On 2022-07-22, Vagrant Cascadian wrote:
> Looks like mes 0.24 test suite failed with GCC-12?
>
> I have not yet tried to reproduce it myself, but this is a bigger issue
> now that GCC-12 is the default compiler in Debian.

Yup, definitely fails with gcc-12.

I've uploaded 0.24-2 to Debian which uses gcc-11 to work around the
problem for now; downgrading the severity accordingly.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016848: librecast: unknown section 'unknown'

[Vagrant Cascadian]

Control: tags 1016848 pending

On 2022-08-08, Graham Inggs wrote:
> Source: librecast
> Version: 0.5.1-2
> Severity: serious
>
> Hi Maintainer
>
> debian/control contains:
>
> Section: unknown

This was fixed in git a couple days ago:

  
https://salsa.debian.org/vagrant/librecast/-/commit/3d1f704693c1bdefc8bc440ee360de5a10932fcf

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016565: marked as pending in librecast

[Vagrant Cascadian]

Control: tag -1 pending

Hello,

Bug #1016565 in librecast reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/vagrant/librecast/-/commit/e1e8d9076afd54bd16b1af9e8f52ff925b9eb5bb


debian/control: Add Breaks and Replaces on liblibrecast0.4. Thanks to
Axel Beckert.  (Closes: #1016565)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1016565

Bug#1012996: mes: ftbfs with GCC-12

[Vagrant Cascadian]

Control: forwarded 1012996 
https://lists.gnu.org/archive/html/bug-mes/2022-07/msg0.html

Bug#1012996: mes: ftbfs with GCC-12

[Vagrant Cascadian]

Looks like mes 0.24 test suite failed with GCC-12?

I have not yet tried to reproduce it myself, but this is a bigger issue
now that GCC-12 is the default compiler in Debian.

live well,
  vagrant

On 2022-06-16, Matthias Klose wrote:
> Package: src:mes
> Version: 0.24-1
> Severity: normal
> Tags: sid bookworm
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-12
>
> [This bug is targeted to the upcoming bookworm release]
>
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-12/g++-12, but succeeds to build with gcc-11/g++-11. The
> severity of this report will be raised before the bookworm release.
>
> The full build log can be found at:
> http://qa-logs.debian.net/2022/06/09/gcc12/mes_0.24-1_unstable_gcc12.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
>   apt-get -t=experimental install g++ 
>
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-11/porting_to.html
>
> GCC 11 defaults to the GNU++17 standard.  If your package installs
> header files in /usr/include, please don't work around C++17 issues
> by choosing a lower C++ standard for the package build, but fix these
> issues to build with the C++17 standard.
>
> [...]
> lib/tests/scaffold/7b-struct-int-array-pointer
> lib/tests/scaffold/7b-struct-int-array
> lib/tests/scaffold/7c-dynarray
> lib/tests/scaffold/7d-cast-char
> lib/tests/scaffold/7e-struct-array-access
> lib/tests/scaffold/7f-struct-pointer-arithmetic
> lib/tests/scaffold/7g-struct-byte-word-field
> lib/tests/scaffold/7h-struct-assign
> lib/tests/scaffold/7i-struct-struct-simple
> lib/tests/scaffold/7i-struct-struct
> lib/tests/scaffold/7k-empty-for
> lib/tests/scaffold/7k-for-each-elem-simple
> lib/tests/scaffold/7k-for-each-elem
> lib/tests/scaffold/7l-struct-any-size-array-simple
> lib/tests/scaffold/7l-struct-any-size-array
> lib/tests/scaffold/7m-struct-char-array-assign
> lib/tests/scaffold/7n-struct-struct-array
> lib/tests/scaffold/7o-struct-pre-post-simple
> lib/tests/scaffold/7o-struct-pre-post
> lib/tests/scaffold/7p-struct-cast
> lib/tests/scaffold/7q-bit-field-simple
> lib/tests/scaffold/7q-bit-field
> lib/tests/scaffold/7r-sign-extend
> lib/tests/scaffold/7s-struct-short
> lib/tests/scaffold/7s-unsigned-compare
> lib/tests/scaffold/7t-function-destruct
> lib/tests/scaffold/7u-double
> lib/tests/scaffold/7u-long-long
> lib/tests/scaffold/7u-ternary-expression
> lib/tests/scaffold/7u-call-ternary
> lib/tests/scaffold/7u-inc-byte-word
> lib/tests/scaffold/7u-struct-func
> lib/tests/scaffold/7u-struct-size10
> lib/tests/scaffold/7u-vstack
> lib/tests/scaffold/70-array-in-struct-init
> lib/tests/scaffold/70-struct-short-enum-init
> lib/tests/scaffold/70-struct-post
> lib/tests/scaffold/70-extern
> lib/tests/scaffold/70-ternary-arithmetic-argument
> lib/tests/scaffold/70-function-modulo
> lib/tests/scaffold/70-or-argument
> lib/tests/setjmp/80-setjmp
> lib/tests/stdio/80-sscanf
> lib/tests/stdlib/80-qsort
> lib/tests/stdlib/80-qsort-dupes
> lib/tests/string/80-strncpy
> lib/tests/string/80-strrchr
> lib/tests/scaffold/82-define
> lib/tests/scaffold/83-heterogenoous-init
> lib/tests/scaffold/84-struct-field-list
> lib/tests/scaffold/85-sizeof
> [0;31m[m
> [0;31mTestsuite summary for GNU Mes[m
> [0;31m[m
> [1m# TOTAL: 180[m
> [0;32m# PASS:  173[m
> # SKIP:  0
> [1;32m# XFAIL: 5[m
> [0;31m# FAIL:  2[m
> # XPASS: 0
> # ERROR: 0
> [0;31m[m
> [0;31mSee gcc-lib/test-suite.log[m
> [0;31mPlease report to bug-...@gnu.org[m
> [0;31m[m
> make[1]: *** [GNUmakefile:147: check] Error 1
> make[1]: Leaving directory '/<>'
> dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 
> returned exit code 2
> make: *** [debian/rules:17: binary] Error 25
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2


signature.asc
Description: PGP signature