Bug#1036620: qthotkey plugin missing

[Andre Heider]

Source: audacious
Version: 4.2-1

The qthotplug plugin is missing, the gtk frontend one is present and 
works fine.


Same for version 4.3.1-1~exp1.

Peeking at [0] I assume it's probably due to the missing 
libqt5x11extras5 dependency?


Thanks!
Andre

[0] 
https://github.com/audacious-media-player/audacious-plugins/pull/86/files

Bug#1031685: redmine doesn't work as thin instance

[Andre Heider]

On 20/02/2023 16:23, Jakob Haufe wrote:

Control: tag -1 + help

On Mon, 20 Feb 2023 15:57:23 +0100
Andre Heider  wrote:


Adding "gem 'thin'" to /usr/share/redmine/Gemfile fixes it for me.

I've no idea about ruby stuff, so that's probably not an appropriate
solution. Does this need to be fixed or can I solve that without
modifying the package's Gemfile?


We discussed the same issue two days ago on IRC.

The correct place for this is /usr/share/redmine/Gemfile.local, so it
will survive updates.


Nice, that worked, thanks!


It is currently undecided whether this needs to be documented somewhere
or whether we can find an automatic way of doing this without a hard
dependency on thin.

Suggestions are welcome.


I tried to find hints in the changelogs of the thin and redmine packages 
and in /usr/share/doc/redmine/examples/thin-redmine.yml first, but 
couldn't find anything.


The latter sounds like a good place?

Cheers,
Andre

Bug#1015796: bullseye backport

[Andre Heider]

This can be closed, a backport is available now.

Thanks!
Andre

Bug#1031685: redmine doesn't work as thin instance

[Andre Heider]

Package: redmine
Version: 5.0.4-2~bpo11+1

I've a ~3 year old redmine+thin+nginx oldstable setup which I couldn't 
use since upgrading to bullseye. Now that there's a backport (many 
thanks for finally having one!), I tried to get that old instance 
working again.


It seems the packages have been updated and the databases migrated just 
fine.


The thin instance is also started:
2023-02-20 15:26:44 +0100 Writing PID to /run/redmine/redmine.0.pid
2023-02-20 15:26:44 +0100 Changing process privilege to www-data:www-data
2023-02-20 15:26:44 +0100 Using rack adapter
2023-02-20 15:27:14 +0100 Thin web server (v1.8.0 codename Possessed Pickle)
2023-02-20 15:27:14 +0100 Maximum connections set to 1024
2023-02-20 15:27:14 +0100 Listening on /run/redmine/redmine.0.sock, 
CTRL+C to stop


But upon the first request it errors out:

2023-02-20 15:27:18 +0100 Exiting!
/usr/lib/ruby/vendor_ruby/zeitwerk/kernel.rb:34:in `require': cannot 
load such file -- thin/request (LoadError)

from /usr/lib/ruby/vendor_ruby/zeitwerk/kernel.rb:34:in `require'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/connection.rb:31:in 
`post_init'

from /usr/lib/ruby/vendor_ruby/em/connection.rb:58:in `block in new'
from /usr/lib/ruby/vendor_ruby/em/connection.rb:49:in `instance_eval'
from /usr/lib/ruby/vendor_ruby/em/connection.rb:49:in `new'
from /usr/lib/ruby/vendor_ruby/eventmachine.rb:1526:in `event_callback'
from /usr/lib/ruby/vendor_ruby/eventmachine.rb:196:in `run_machine'
from /usr/lib/ruby/vendor_ruby/eventmachine.rb:196:in `run'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/backends/base.rb:75:in 
`start'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/server.rb:162:in 
`start'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/controllers/controller.rb:87:in 
`start'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/runner.rb:203:in 
`run_command'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/lib/thin/runner.rb:159:in 
`run!'
from 
/usr/lib/aarch64-linux-gnu/rubygems-integration/2.7.0/gems/thin-1.8.0/bin/thin:6:in 
`'

from /usr/bin/thin:23:in `load'
from /usr/bin/thin:23:in `'

Adding "gem 'thin'" to /usr/share/redmine/Gemfile fixes it for me.

I've no idea about ruby stuff, so that's probably not an appropriate 
solution. Does this need to be fixed or can I solve that without 
modifying the package's Gemfile?


Thanks and Cheers,
Andre

Bug#1021211: remmina: switch to libsoup3

[Andre Heider]

Can we please have spice back?

It's been half a year, and my patch with an alternative solution still 
works fine with 1.4.29 (which is what I'm using for that period on a 
daily basis):


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015147#27

Thanks,
Andre

Bug#1016640: gnome-terminal: Size resets to 80x24, when another window gets focus (only tested on gnome-shell)

[Andre Heider]

Same here on XFCE with gnome-terminal.

Upstream has fixed it with:
https://gitlab.gnome.org/GNOME/vte/-/commit/a07cfcde3e595084ebc72c96c41857bf05c4c668

Can this patch be backported for the debian package, please?

Thanks,
Andre

Bug#1015147: remmina: incompatible with spice-gtk built against libsoup3

[Andre Heider]

I looked into it, and I guess the www plugin is currently broken (didn't 
confirm as I don't use it), as it also has a libsoup2 dependency here, 
but libwebkit2gtk is built with libsoup-3.0.


Attached two patches to just exclude the news dialog (to avoid porting 
it to libsoup3), switch to libsoup3 and reenable the spice plugin.


Seems to work fine with some light testing.

Thanks,
AndreFrom ab5199bac542ca74f0bedb9e0260519521c386d5 Mon Sep 17 00:00:00 2001
From: Andre Heider 
Date: Thu, 4 Aug 2022 09:36:39 +0200
Subject: [PATCH 1/2] don't build the news dialog and switch to libsoup-3.0

---
 debian/changelog  |   4 +
 debian/control|   2 +-
 ...news-dialog-and-switch-to-libsoup-3..patch | 132 ++
 debian/patches/series |   1 +
 4 files changed, 138 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/0001-don-t-build-the-news-dialog-and-switch-to-libsoup-3..patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index a6a32d316..55adbab4b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,7 @@
+remmina (1.4.27+dfsg-3) UNRELEASED; urgency=medium
+
+  * don't build the news dialog and switch to libsoup-3.0
+
 remmina (1.4.27+dfsg-2) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff --git a/debian/control b/debian/control
index 16c2de186..43649f628 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ Build-Depends:
  libkf5wallet-dev,
  libsecret-1-dev,
  libsodium-dev,
- libsoup2.4-dev,
+ libsoup-3.0-dev,
 # libspice-client-glib-2.0-dev,
 # libspice-client-gtk-3.0-dev,
 # libspice-protocol-dev,
diff --git a/debian/patches/0001-don-t-build-the-news-dialog-and-switch-to-libsoup-3..patch b/debian/patches/0001-don-t-build-the-news-dialog-and-switch-to-libsoup-3..patch
new file mode 100644
index 0..036b18aa1
--- /dev/null
+++ b/debian/patches/0001-don-t-build-the-news-dialog-and-switch-to-libsoup-3..patch
@@ -0,0 +1,132 @@
+From 328a31a8aeacdbd5bd97acedfba04fb85747a804 Mon Sep 17 00:00:00 2001
+From: Andre Heider 
+Date: Thu, 4 Aug 2022 09:29:00 +0200
+Subject: [PATCH] don't build the news dialog and switch to libsoup-3.0
+
+---
+ ...indLIBSOUP24.cmake => FindLIBSOUP30.cmake} | 24 +--
+ plugins/www/CMakeLists.txt| 10 
+ src/CMakeLists.txt| 10 
+ src/remmina.c |  2 +-
+ 4 files changed, 18 insertions(+), 28 deletions(-)
+ rename cmake/{FindLIBSOUP24.cmake => FindLIBSOUP30.cmake} (62%)
+
+diff --git a/cmake/FindLIBSOUP24.cmake b/cmake/FindLIBSOUP30.cmake
+similarity index 62%
+rename from cmake/FindLIBSOUP24.cmake
+rename to cmake/FindLIBSOUP30.cmake
+index 96ec22239..53eca15ca 100644
+--- a/cmake/FindLIBSOUP24.cmake
 b/cmake/FindLIBSOUP30.cmake
+@@ -21,26 +21,26 @@
+ 
+ include(FindPackageHandleStandardArgs)
+ 
+-pkg_check_modules(PC_LIBSOUP24 libsoup-2.4)
++pkg_check_modules(PC_LIBSOUP30 libsoup-3.0)
+ 
+ 
+-find_path(LIBSOUP24_INCLUDE_DIR NAMES libsoup/soup.h
+-	HINTS ${PC_LIBSOUP24_INCLUDEDIR} ${PC_LIBSOUP24_INCLUDE_DIRS}
++find_path(LIBSOUP30_INCLUDE_DIR NAMES libsoup/soup.h
++	HINTS ${PC_LIBSOUP30_INCLUDEDIR} ${PC_LIBSOUP30_INCLUDE_DIRS}
+ )
+ 
+-find_library(LIBSOUP24_LIBRARY
+-	NAMES soup-2.4
+-	HINTS ${PC_LIBSOUP24_LIBDIR} ${PC_LIBSOUP24_LIBRARY_DIRS}
++find_library(LIBSOUP30_LIBRARY
++	NAMES soup-3.0
++	HINTS ${PC_LIBSOUP30_LIBDIR} ${PC_LIBSOUP30_LIBRARY_DIRS}
+ 	)
+ 
+-if (LIBSOUP24_INCLUDE_DIR AND LIBSOUP24_LIBRARY)
+-	find_package_handle_standard_args(LIBSOUP24 DEFAULT_MSG LIBSOUP24_LIBRARY LIBSOUP24_INCLUDE_DIR)
++if (LIBSOUP30_INCLUDE_DIR AND LIBSOUP30_LIBRARY)
++	find_package_handle_standard_args(LIBSOUP30 DEFAULT_MSG LIBSOUP30_LIBRARY LIBSOUP30_INCLUDE_DIR)
+ endif()
+ 
+-if (LIBSOUP24_FOUND)
+-	set(LIBSOUP24_LIBRARIES ${LIBSOUP24_LIBRARY})
+-	set(LIBSOUP24_INCLUDE_DIRS ${LIBSOUP24_INCLUDE_DIR})
++if (LIBSOUP30_FOUND)
++	set(LIBSOUP30_LIBRARIES ${LIBSOUP30_LIBRARY})
++	set(LIBSOUP30_INCLUDE_DIRS ${LIBSOUP30_INCLUDE_DIR})
+ endif()
+ 
+-mark_as_advanced(LIBSOUP24_INCLUDE_DIR LIBSOUP24_LIBRARY)
++mark_as_advanced(LIBSOUP30_INCLUDE_DIR LIBSOUP30_LIBRARY)
+ 
+diff --git a/plugins/www/CMakeLists.txt b/plugins/www/CMakeLists.txt
+index cd1ab3a32..7cddcac5d 100644
+--- a/plugins/www/CMakeLists.txt
 b/plugins/www/CMakeLists.txt
+@@ -45,12 +45,12 @@ set_target_properties(remmina-plugin-www PROPERTIES NO_SONAME 1)
+ 
+ add_definitions(${WEBKIT2GTK_CFLAGS_OTHER})
+ 
+-find_required_package(LIBSOUP24)
+-if(LIBSOUP24_FOUND)
+-include_directories(${REMMINA_COMMON_INCLUDE_DIRS} ${WEBKIT2GTK_INCLUDE_DIRS} ${LIBSOUP24_INCLUDE_DIRS})
+-target_link_libraries(remmina-plugin-www ${REMMINA_COMMON_LIBRARIES} ${LIBSOUP24_LIBRARIES} ${WEBKIT2GTK_LIBRARIES})
++find_required_package(LIBSOUP30)
++if(LIBSOUP30_FOUND)
++include_directories(${REMMINA_COMMON_INCLUDE_DIRS} ${WEBKIT2GTK_INCLUD

Bug#1015147: remmina: incompatible with spice-gtk built against libsoup3

[Andre Heider]

Hi,

this is really unfortunate, spice is _the_ protocol to connect to local VMs.

According to the upstream bug in #1, libsoup is just used for the 
internal news thingy. Which is arguably useless from debian's point of view.


Can't we disable that and keep spice, please?

Thanks,
Andre

Bug#1015796: bullseye backport

[Andre Heider]

Source: redmine

Can we have a backport for bullseye please?

The wiki claims it'll come at some point [0], and Rails 6 is there, so 
are we there yet? :)


[0] https://wiki.debian.org/Redmine

Thanks!
Andre

Bug#910261: New 0.2 release

[Andre Heider]

Woot, just shy of 4 years later and this can finally be closed :)

Bug#1015239: libwine-dev:amd64 and libwine-dev:i386 can not coexist

[Andre Heider]

Source: wine
Version: 7.0~repack-4

First of all: Thanks for the v7.0 update, much appreciated!

But the packages now conflict with each other, they both contain the 
same headers.


That prevents installing them both and hence building apps requiring 
libwine for both archs.


Can that be fixed with e.g. a new common header -dev package, please?

Thanks!
Andre

Bug#826045: systemd: New kernels are not booted

[Andre Heider]

On 30/01/2022 21:51, Michael Biebl wrote:

For anyone interested, I've submitted
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/138

Which also ships some very basic /etc/kernel hooks and a simplistic 
postinst.


Would welcome feedback / follow-up fixes if needed.


That looks nice, thanks for working on this!

I'm still using the very same scripts I posted above, it's still working 
like a charm after 5 years with all the kernel updates and whatnot :)


I haven't tested your PR, and I lack the confirmed account on salsa to 
comment there, so I'll add it here, including answers to questions over 
there:


- removing sd-boot from the root fs won't render the system unbootable, 
since sd-boot needs to be installed to the efi partition. There's 
`bootctl remove` for that


- likewise with updating it. `bootctl status` reports "systemd-boot 
247.9-4" here, while the systemd package is already at 250.3-2, I'd have 
to `bootctl update` it to update it to that version


- checking if sd-boot is used can be checked via bootctl and should 
probably be used by the containing scripts instead of test -d /boot/efi:

$ bootctl is-installed; echo $?
yes
0

- contrary to the comments on salsa `kernel-install` is not part of your 
new package and I think it makes sense to move there. While it's using 
the "Boot Loader Specification", it's only used for stuff that's already 
part of this package. Even if there's a need for it without using 
sd-boot, one can install the sd-boot package without actually using it 
for booting the box (assuming the package scripts don't enforce it)


Regards,
Andre

Bug#967266: Update to v1.1.0

[Andre Heider]

Can we please get an update to v1.1.0?
That already updates the gtk module for gtk-3.0 ;)

Thanks,
Andre

Bug#910261: Update opus-tools to 0.2

[Andre Heider]

Hi there,

newer version require libopusenc, which I guess is the holdup?

There's [0], but I don't know how this process works. How does that get 
in so opus-tools can be updated?


Thanks,
Andre

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922102

Bug#995926: Error validating Let's Encrypt cert chains

[Andre Heider]

On 11/10/2021 18:41, Andreas Metzler wrote:

This looks like
https://github.com/lavv17/lftp/issues/641
which has a fix in upstream GIT.


That indeed looks likely, thanks!

Bug#995926: Error validating Let's Encrypt cert chains

[Andre Heider]

The audacious cmdline from above works now, I guess because of the 
resolved bug #995432 ?


lftp still fails though.

Bug#995926: Error validating Let's Encrypt cert chains

[Andre Heider]

Source: gnutls28
Version: 3.7.2-2

Apps using gnutls fail to connect to servers using a Let's Encrypt 
certificate which are cross-signed by the now expired DST Root CA X3, 
see [0].


Examples:

$ lftp https://shop.bbc.com
cd: Fatal error: Certificate verification: Not trusted 
(93:3C:6D:DE:E9:5C:9C:41:A4:0F:9F:50:49:3D:82:BE:03:AD:87:BF)


$ audacious https://stream.tonkuhle.de/tonkuhle.mp3
ERROR neon.cc:542 [open_request]: <0x7f68d4025660> Could not open URL: 1 (0)
ERROR neon.cc:545 [open_request]: <0x7f68d4025660> neon error string: 
Server certificate verification failed: bad certificate chain

ERROR neon.cc:756 [fopen]: <0x7f68d4025660> Could not open URL
ERROR util.cc:269 [audgui_simple_message]: Error playing 
https://stream.tonkuhle.de/tonkuhle.mp3:

Server certificate verification failed: bad certificate chain

[0] https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

Bug#990210: fixed in cups-pdf 3.0.1-12

[Andre Heider]

Hi Till,

On 01/10/2021 12:32, Till Kamppeter wrote:
Andre, could you attach your PostScript file, once the original and also 
the one you get after pre-processing when using "GSCall echo %s %s %s;

cp %s /tmp"? Thanks.


attached a patch for the original .ps file, see the first post for a link.

But maybe that patch already hints at the problem?

Cheers,
Andre

all.patch.gz
Description: application/gzip

Bug#990210: fixed in cups-pdf 3.0.1-12

[Andre Heider]

On 28/09/2021 14:03, Martin-Éric Racine wrote:

ti 28. syysk. 2021 klo 8.24 Andre Heider (a.hei...@gmail.com) kirjoitti:

Thanks, works out of the box now!


Can you confirm that 3.0.1-9 (stable) doesn't work while 3.0.1-12
(unstable) works?


Nope, I'm on testing and updated from 3.0.1-11 to 3.0.1-12 this morning, 
and that fixed it for me. But because the issue was introduced due to 
ghostscript 9.54 on testing.


Stable seems to use ghostscript 9.53, which is likely not affected by this.

See also:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=180419375973b9ce4664286a67106d712260ef7f

So if the question is if this is required to be backported to stable:
Only if stable updates to ghostscript to 9.54.
But it won't hurt either, it's just a noop anyway and will get rid of 
the deprecated warning mentioned by the OP.


Cheers,
Andre

Bug#990210: fixed in cups-pdf 3.0.1-12

[Andre Heider]

Thanks, works out of the box now!

Bug#990210: printer-driver-cups-pdf: produces empty output with gs exit 256, gs from log works

[Andre Heider]

On 27/09/2021 12:17, Martin-Éric Racine wrote:

Andre,

You might wanna read up on what constitutes Severity: critical. Fails
at producing a file is not a valid criteria for such a severity.


Ok, so "grave" it is then... Didn't realize "critical" isn't per package 
but system-wide.


But it wasn't set anyway afaict, I'm not using the debian bug tracker 
that much ;)


Cheers,
Andre

Bug#990210: printer-driver-cups-pdf: produces empty output with gs exit 256, gs from log works

[Andre Heider]

On 27/09/2021 12:17, Martin-Éric Racine wrote:

Andre,

You might wanna read up on what constitutes Severity: critical. Fails
at producing a file is not a valid criteria for such a severity.


Will do, but since the package fails at its own single purpose I did 
consider that as appropriate.


Cheers,
Andre

Bug#990210: printer-driver-cups-pdf: produces empty output with gs exit 256, gs from log works

[Andre Heider]

Severity: critical

Printing now always produces an empty pdf for me.
It indeed is the 'setpdfwrite' operator that's responsible for this.

Attached patch from arch fixes it:
https://github.com/archlinux/svntogit-packages/blob/packages/cups-pdf/trunk/remove-deprecated-ghostscript-setpdfwrite-operator.diff--- cups-pdf-3.0.1/src/cups-pdf.h	2017-02-24 16:31:00.901661190 +0100
+++ cups-pdf-3.0.1/src/cups-pdf.h.new	2021-04-06 17:05:57.553854742 +0200
@@ -58,7 +58,7 @@
   { "AnonDirName", SEC_CONF|SEC_PPD, { "/var/spool/cups-pdf/ANONYMOUS" } },
   { "AnonUser", SEC_CONF|SEC_PPD, { "nobody" } },
   { "GhostScript", SEC_CONF|SEC_PPD, { "/usr/bin/gs" } },
-  { "GSCall", SEC_CONF|SEC_PPD, { "%s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=\"%s\" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s" } },
+  { "GSCall", SEC_CONF|SEC_PPD, { "%s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=\"%s\" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s" } },
   { "Grp", SEC_CONF|SEC_PPD, { "lp" } },
   { "GSTmp", SEC_CONF|SEC_PPD, { "TMPDIR=/var/tmp" } },
   { "Log", SEC_CONF|SEC_PPD, { "/var/log/cups" } },
--- cups-pdf-3.0.1/extra/cups-pdf.conf	2017-02-24 16:30:18.476524443 +0100
+++ cups-pdf-3.0.1/extra/cups-pdf.conf.new	2021-04-06 17:06:26.364602843 +0200
@@ -250,9 +250,9 @@
 ### Key: GSCall (config)
 ## command line for calling GhostScript (!!! DO NOT USE NEWLINES !!!)
 ## MacOSX: for using pstopdf set this to %s %s -o %s %s
-### Default: %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s
+### Default: %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s
 
-#GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s
+#GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c -f %s
 
 ### Key: PDFVer (config, ppd, lptopions)
 ##  PDF version to be created - can be "1.5", "1.4", "1.3" or "1.2" 

Bug#994873: libdrm-dev: mssing dependency on valgrind

[Andre Heider]

I did some more digging and it looks like valgrind can just be disabled:
https://salsa.debian.org/xorg-team/lib/libdrm/-/blob/debian-unstable/meson.build#L256

And AFAICT it's only used for debugging purposes ("ioctl annotations"), 
on intel and freedreno:

$ git grep HAVE_VALGRIND
freedreno/freedreno_priv.h:#if HAVE_VALGRIND
intel/intel_bufmgr_gem.c:#if HAVE_VALGRIND
intel/intel_bufmgr_gem.c:#if HAVE_VALGRIND
intel/intel_bufmgr_gem.c:#if HAVE_VALGRIND

For comparison:

arch disables it:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libdrm-git#n43

suse too (if I read that "%if 0%{?with_valgrind_support:1}" correctly):
https://build.opensuse.org/package/view_file/openSUSE:Factory/libdrm/libdrm.spec?expand=1

fedora enables it on supported arch (but has a valgrind-devel package)
https://src.fedoraproject.org/rpms/libdrm/blob/rawhide/f/libdrm.spec

I propose to:
- disable valgrind for now
- reenable it once there's a multiarch compatible valgrind-devel package
  See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731228

Bug#994873: libdrm-dev: mssing dependency on valgrind

[Andre Heider]

This is not multiarch compatible, libdrm-dev can't be coinstalled with 
libdrm-dev:i386 now.

Bug#992605: libifd-cyberjack6: uses non-existing group pcscd in udev rules

[Andre Heider]

See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

Bug#969206: Info received (redmine: Could not find gem 'rails (~> 5.2.2)' in any of the gem sources listed in your Gemfile)

[Andre Heider]

Just going by the upstream commit history it looks like the initial 
rails>=6 transition is done.


Can we get a pre v5 release experimental package please?

Thanks,
Andre

Bug#992396: debianutils: tempfile binary is gone, breaks Xsession

[Andre Heider]

I guess more transitions are required, just by grep'ing in my local /usr 
I see these:


/usr/bin/vimtutor:TUTORCOPY=`mktemp $tmp/tutorXX || tempfile -p 
tutor || echo none`

/usr/bin/bzexe:tmpfile=`tempfile -p gztmp -d /tmp` || exit 1
/usr/bin/mupdf:tmp=$(tempfile -s .pdf)
/usr/sbin/install-keymap:TMP=`tempfile`
/usr/sbin/install-keymap:NEW=`tempfile --suffix .gz`

Bug#992396: debianutils: tempfile binary is gone, breaks Xsession

[Andre Heider]

On Wed, 18 Aug 2021 23:19:17 +1200 Jean-Francois Pirus 
 wrote:

Duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992385


No, not really.

This removes a tool which is still in use. I get the desire to remove 
deprecated stuff, but the user friendly way is to communicate the 
removal of the usage to packages using said tool first, and only then 
removing the tool itself.


Isn't that what transitions are used for?

This change broke X for everyone on testing, that's not a very nice way 
forward.


As a user I've never seen the deprecated output anywhere. It probably 
never for printed anywhere for Xsession?

Bug#992398: Xsession requires tempfile

[Andre Heider]

Source: debianutils
Version: 5.0.1-1
Severity: critical

X fails to start up, basically rendering the whole graphical login useless.

/etc/X11/Xsession:elif ERRFILE=$(tempfile 2> /dev/null); then
/etc/X11/Xsession:# error from tempfile and echo go to the error file to 
aid the user in

/etc/X11/Xsession:WRITE_TEST=$(tempfile)

Really, how did this make it in?

Bug#969518: Add missing ESPRESSObin variants

[Andre Heider]

Ping.
Anyone? Bueller?

Bug#976654: fixed in pipewire 0.3.19-1

[Andre Heider]

Nice, thanks!

Two minor things:

* pipewire-pulse.[socket|service] isn't installed
  this works for me:
  $ cp -a 
/usr/share/doc/pipewire/examples/systemd/user/pipewire-pulse.* 
/usr/lib/systemd/user


* pipewire should recommend rtkit
  without:
pipewire[13006]: could not set nice-level to -11: No such file or 
directory
pipewire[13006]: could not make thread realtime: No such file or 
directory

  installing rtkit fixes that

With the first change these packages can be used to replace the 
pulseaudio server without further changes.


Regards,
Andre

Bug#976654: pipewire: please provide pipewire-pulse

[Andre Heider]

Yes, please update the package to 0.3.17 ;)

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

On 15/10/2020 16:11, Heinrich Schuchardt wrote:

On 15.10.20 15:13, Andre Heider wrote:

On 04/09/2020 07:20, Andre Heider wrote:




Of those, these are part of all.db:
rockchip/rk3399-evb.dts
apm/apm-mustang.dtb

The former is an evaluation board, added by Heinrich (cc'ed) in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899090
Given the nature of these boards, I guess Heinrich knows how to adapt
$console - if he's even using it.

The latter is not part of u-boot mainline, so I claim that one is free
to ignore :)

Given all that, I propose the attached patch.


I still think this is the best option, any issues with that patch?


Environment variable $console should not contain any "console=" in U-Boot.

The current flash_kernel script is correct and should not be changed.
Otherwise you will break working boards.

Instead fix upstream U-Boot where $console is set incorrectly.

Best regards

Heinrich



Ok, so it seems like this is impossible to solve since various places 
depend on either behavior.


Please close this then.

Bug#969518: (no subject)

[Andre Heider]

Gentle ping

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

On 04/09/2020 07:20, Andre Heider wrote:




Of those, these are part of all.db:
rockchip/rk3399-evb.dts
apm/apm-mustang.dtb

The former is an evaluation board, added by Heinrich (cc'ed) in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899090
Given the nature of these boards, I guess Heinrich knows how to adapt 
$console - if he's even using it.


The latter is not part of u-boot mainline, so I claim that one is free 
to ignore :)


Given all that, I propose the attached patch.


I still think this is the best option, any issues with that patch?

Regards,
Andre

Bug#969515: (no subject)

[Andre Heider]

ping?

Patch is a plain bugfix, so I think uncontroversial?

Bug#969515: flash-kernel: Add vendor path for some arm64 machines

[Andre Heider]

On 04/09/2020 02:30, Vagrant Cascadian wrote:

I'm submitting this to the Debian bug tracking system, since this isn't
directly related to u-boot. I've dropped most of the CCs on the thread,
presumably should also drop the u-boot CC on follow-ups.


Thanks!

For the record: I added the path for *all* missing arm64 boards, not 
just some :)



Support for installing in vendor subdirs was added to flash-kernel 3.91
from 2018, and I believe the vendor subdirs are included in the
debian-installer boot media as well.


alright, but if the vendor path is missing from flash-kernel's db,
everything silently works with a flattened tree. See attached patch, now
it works here too :)


Yes, I believe this was intentional to smooth the transition without
breaking booting for some machines...


I guess flash-kernel should error out if it's missing for arm=arm64?

Thanks,
Andre

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

On 04/09/2020 12:50, Heinrich Schuchardt wrote:

On 04.09.20 09:54, Andre Heider wrote:

On 04/09/2020 09:20, Heinrich Schuchardt wrote:

On 04.09.20 07:20, Andre Heider wrote:

On 04/09/2020 03:10, Vagrant Cascadian wrote:

On 2020-08-28, Andre Heider wrote:

Stats:
Going by u-boot upstream, only 17 of +700 boards set $console (grep
for


You seem


CONFIG_DEFAULT_CONSOLE, which too is deprecated).


I found no CONFIG_DEFAULT_CONSOLE is deprecated?


That's just by going by
- only a few configs use it
- it's listed in scripts/config_whitelist.txt, so knobs not yet
converted to Kconfig


On the Wandboard Quad which is one of the elder boards we have:

=> echo $console
ttymxc0

It is defined here:

include/configs/wandboard.h:48: "console=ttymxc0\0" \


That...




include/configs/odroid.h
include/configs/odroid_xu3.h
include/configs/s5p_goni.h
include/configs/s5pc210_universal.h
include/configs/trats.h
include/configs/trats2.h


and all of these are 32bit arm boards, which is likely a can of worms to
open at this point in time. I'm not sure we want to go there, that's why
I proposed to only change the 64bit arm bootscript.

Thanks,
Andre


Which armv8 boards have a problem with upstream U-Boot?

E.g. your example in include/configs/mvebu_armada-37xx.h does not exist
in U-Boot v2020.07


The issue came up on the posted patch adding it:
https://patchwork.ozlabs.org/project/uboot/patch/20200824142502.7281-4-p...@kernel.org/

Regards,
Andre

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

On 04/09/2020 09:20, Heinrich Schuchardt wrote:

On 04.09.20 07:20, Andre Heider wrote:

On 04/09/2020 03:10, Vagrant Cascadian wrote:

On 2020-08-28, Andre Heider wrote:

Stats:
Going by u-boot upstream, only 17 of +700 boards set $console (grep for


You seem


CONFIG_DEFAULT_CONSOLE, which too is deprecated).


I found no CONFIG_DEFAULT_CONSOLE is deprecated?


That's just by going by
- only a few configs use it
- it's listed in scripts/config_whitelist.txt, so knobs not yet 
converted to Kconfig



On the Wandboard Quad which is one of the elder boards we have:

=> echo $console
ttymxc0

It is defined here:

include/configs/wandboard.h:48: "console=ttymxc0\0" \


That...




include/configs/odroid.h
include/configs/odroid_xu3.h
include/configs/s5p_goni.h
include/configs/s5pc210_universal.h
include/configs/trats.h
include/configs/trats2.h


and all of these are 32bit arm boards, which is likely a can of worms to 
open at this point in time. I'm not sure we want to go there, that's why 
I proposed to only change the 64bit arm bootscript.


Thanks,
Andre

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

On 04/09/2020 03:10, Vagrant Cascadian wrote:

On 2020-08-28, Andre Heider wrote:

Stats:
Going by u-boot upstream, only 17 of +700 boards set $console (grep for
CONFIG_DEFAULT_CONSOLE, which too is deprecated).

Going by linux upstream, 112 of 125 arm64 boards used "stdout-path":
$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|xargs strings
-f|grep stdout-path|wc -l
112

$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|wc -l
125


Those numbers sound pretty convincing, certainly for arm64...


Agreed, so let's concentrate on arm64 first.

Some detective work, let's see which boards are missing stdout-path:

$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb > all
$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|xargs strings 
-f|grep -w stdout-path|cut -d':' -f1 > hits

$ diff -u all hits
--- all 2020-09-04 06:46:07.556097717 +0200
+++ hits2020-09-04 06:45:58.171811652 +0200
@@ -1,11 +1,8 @@
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3399-firefly.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3399-sapphire-excavator.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3399-evb.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3368-r88.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3368-px5-evb.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3328-rock64.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3368-lion-haikou.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3399-sapphire.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3399-gru-kevin.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3368-orion-r68-meta.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/rockchip/rk3328-roc-cc.dtb
@@ -21,12 +18,9 @@
 /usr/lib/linux-image-4.19.0-10-arm64/marvell/armada-8040-db.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/marvell/armada-3720-db.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/marvell/armada-8080-db.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/apm/apm-merlin.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/apm/apm-mustang.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-gxl-s905w-tx3-mini.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-gxm-q201.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-gxl-s805x-p241.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-axg-s400.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-gxbb-vega-s95-meta.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-gxl-s905d-p231.dtb

/usr/lib/linux-image-4.19.0-10-arm64/amlogic/meson-gxl-s905x-nexbox-a95x.dtb
@@ -86,18 +80,11 @@
 /usr/lib/linux-image-4.19.0-10-arm64/qcom/apq8016-sbc.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/qcom/apq8096-db820c.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/qcom/sdm845-mtp.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/arm/foundation-v8-gicv3.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/arm/juno.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/arm/rtsm_ve-aemv8a.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/arm/vexpress-v2f-1xv7-ca53x2.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/arm/foundation-v8-gicv3-psci.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/arm/foundation-v8.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/arm/juno-r2.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/arm/juno-r1.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/arm/foundation-v8-psci.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/cavium/thunder2-99xx.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/cavium/thunder-88xx.dtb
-/usr/lib/linux-image-4.19.0-10-arm64/hisilicon/hip06-d03.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/hisilicon/hip07-d05.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/hisilicon/hi6220-hikey.dtb
 /usr/lib/linux-image-4.19.0-10-arm64/hisilicon/hip05-d02.dtb

For linux-image-5.6.0-0.bpo.2-arm64:
diff -u all hits
--- all 2020-09-04 06:47:52.363292463 +0200
+++ hits2020-09-04 06:47:43.227013979 +0200
@@ -7,7 +7,6 @@
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3399-firefly.dtb

/usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3399-sapphire-excavator.dtb

/usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3399-gru-scarlet-inx.dtb
-/usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3399-evb.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3399-pinebook-pro.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3368-r88.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/rockchip/rk3399-rock-pi-4.dtb
@@ -51,7 +50,6 @@
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/marvell/cn9130-db.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/marvell/cn9132-db.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/marvell/armada-8080-db.dtb
-/usr/lib/linux-image-5.6.0-0.bpo.2-arm64/freescale/fsl-ls1088a-qds.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/freescale/fsl-lx2160a-qds.dtb

/usr/lib/linux-image-5.6.0-0.bpo.2-arm64/freescale/fsl-lx2160a-clearfog-cx.dtb
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/freescale/fsl-lx2160a-rdb.dtb
@@ -59,23 +57,14 @@
 /usr/lib/linux-image-5.6.0-0.bpo.2-arm64/freescale/fsl-ls2080a-rdb.dtb

/usr/lib/linux-image-5.6.0-0.bpo.2-arm64/frees

Bug#969518: Add missing ESPRESSObin variants

[Andre Heider]

Source: flash-kernel

Linux added support for these [0]. Each has its own model identifier, so
add them here too.

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=447b8789359f9a5e6567c4044d18abaa7de68930
>From a3a8d98a1518a9b922f192b4c287b8fc9c668390 Mon Sep 17 00:00:00 2001
From: Andre Heider 
Date: Fri, 4 Sep 2020 06:32:07 +0200
Subject: [PATCH] Add missing ESPRESSObin variants

Linux added support for these [0]. Each has its own model identifier, so
add them here too.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=447b8789359f9a5e6567c4044d18abaa7de68930
---
 db/all.db | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/db/all.db b/db/all.db
index d7303f7..662416f 100644
--- a/db/all.db
+++ b/db/all.db
@@ -492,6 +492,24 @@ Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
 
+Machine: Globalscale Marvell ESPRESSOBin Board (eMMC)
+DTB-Id: marvell/armada-3720-espressobin-emmc.dts
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
+Machine: Globalscale Marvell ESPRESSOBin Board V7
+DTB-Id: marvell/armada-3720-espressobin-v7.dts
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
+Machine: Globalscale Marvell ESPRESSOBin Board V7 (eMMC)
+DTB-Id: marvell/armada-3720-espressobin-v7-emmc.dts
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: Globalscale Mirabox
 Kernel-Flavors: armmp
 DTB-Id: armada-370-mirabox.dtb
-- 
2.28.0

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

On 27/08/2020 22:43, Vagrant Cascadian wrote:

Control: severity 969070 important

On 2020-08-27, Andre Heider wrote:

Since [0] flash-kernel does:

if test -n "${console}"; then
  setenv bootargs "${bootargs} console=${console}"
fi

The common $console format as set by u-boot includes the leading "console=":
include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/mvebu_armada-37xx.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
include/configs/mvebu_armada-37xx.h:"console="
CONFIG_DEFAULT_CONSOLE "\0" \
include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/odroid.h:   "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/odroid_xu3.h:   "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/s5p_goni.h: "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/s5pc210_universal.h:"console=" CONFIG_DEFAULT_CONSOLE \
include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC1,115200n8\0"
include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/trats.h:"console=" CONFIG_DEFAULT_CONSOLE \
include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE
"console=ttySAC2,115200n8\0"
include/configs/trats2.h:   "console=" CONFIG_DEFAULT_CONSOLE \

So on some boards we end up with bootargs containing
"console=console=...", which, combined with a systemd bug [1] (present
in buster), makes the system unbootable:
[4.632197] systemd-udevd[90]: Starting version 241
[4.639324] systemd-udevd[91]: Failed to create udev control event
source: Operation not permitted



In debian's u-boot package, this has been patched out for some targets
(and upstream originally included the patches, but eventually reverted).

The problem stems from an inconsistancy in u-boot, as some platforms use
this argument differently(especially when you get into vendor forks of
u-boot), and I don't believe u-boot has pattern matching to be able to
handle this properly (e.g. behave differently when console=* is set).




Doing a "env delete console" and the system boots up properly. That
includes the kernel output over serial, since the kernel dts files have
contain "chosen { stdout-path =  };".


Not all systems have stdout-path defined in the device-tree.
Maybe now those are the exceptions...


So I'd say appending $console to $bootargs is some historical leftover,
and it can just be removed from the generic scripts.


The problem is that *not* doing this with console can also result in an
unbootable system.


Huh, how does that break?


Reverting this would be breaking one thing to fix another. There's no
"correct" here, only different. :/


flash-kernel supports assigning different boot scripts per boards. I 
mean, we could get rid of $console from the generic scripts, and then 
use a different one with it for boards requiring it.


Stats:
Going by u-boot upstream, only 17 of +700 boards set $console (grep for 
CONFIG_DEFAULT_CONSOLE, which too is deprecated).


Going by linux upstream, 112 of 125 arm64 boards used "stdout-path":
$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|xargs strings 
-f|grep stdout-path|wc -l

112

$ find /usr/lib/linux-image-4.19.0-10-arm64 -name \*.dtb|wc -l 
  125


I didn't check 32bit arm, but going by those numbers we could at least 
drop it for bootscript/arm64/bootscr.uboot-generic (I ran into this 
issue on arm64).


Regards,
Andre

Bug#969070: $console handling might result in unbootable system

[Andre Heider]

Source: flash-kernel
Severity: critical

Since [0] flash-kernel does:

  if test -n "${console}"; then
setenv bootargs "${bootargs} console=${console}"
  fi

The common $console format as set by u-boot includes the leading "console=":
include/configs/arndale.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC2,115200n8\0"
include/configs/espresso7420.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/mvebu_armada-37xx.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000"
include/configs/mvebu_armada-37xx.h:"console=" 
CONFIG_DEFAULT_CONSOLE "\0" \
include/configs/odroid.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"

include/configs/odroid.h:   "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/odroid_xu3.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC2,115200n8\0"

include/configs/odroid_xu3.h:   "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/origen.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/peach-pi.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/peach-pit.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/s5p_goni.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC2,115200n8\0"

include/configs/s5p_goni.h: "console=" CONFIG_DEFAULT_CONSOLE \
include/configs/s5pc210_universal.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"

include/configs/s5pc210_universal.h:"console=" CONFIG_DEFAULT_CONSOLE \
include/configs/smdk5250.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/smdk5420.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/smdkv310.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC2,115200n8\0"
include/configs/snow.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/spring.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC1,115200n8\0"
include/configs/trats.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC2,115200n8\0"

include/configs/trats.h:"console=" CONFIG_DEFAULT_CONSOLE \
include/configs/trats2.h:#define CONFIG_DEFAULT_CONSOLE 
"console=ttySAC2,115200n8\0"

include/configs/trats2.h:   "console=" CONFIG_DEFAULT_CONSOLE \

So on some boards we end up with bootargs containing 
"console=console=...", which, combined with a systemd bug [1] (present 
in buster), makes the system unbootable:

[4.632197] systemd-udevd[90]: Starting version 241
[4.639324] systemd-udevd[91]: Failed to create udev control event
source: Operation not permitted


Doing a "env delete console" and the system boots up properly. That 
includes the kernel output over serial, since the kernel dts files have 
contain "chosen { stdout-path =  };".


So I'd say appending $console to $bootargs is some historical leftover, 
and it can just be removed from the generic scripts.


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783074
[1] https://github.com/systemd/systemd/issues/13332

Bug#968224: multilib compiler doesn't find its libraries

[Andre Heider]

Source: gcc-10
Version: 10.2.0-5

This used to work with earlier gcc versions:
gcc -m32 /dev/null
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc

/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc

/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status

The cross compiler works though:
i686-linux-gnu-gcc -m32 /dev/null
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: 
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/lib/../lib/Scrt1.o: 
in function `_start':

(.text+0x28): undefined reference to `main'
collect2: error: ld returned 1 exit status

Installed packages:
ii  gcc   4:10.1.0-1 
 amd64GNU C compiler
ii  gcc-1010.2.0-5 
 amd64GNU C compiler
ii  gcc-10-base:amd64 10.2.0-5 
 amd64GCC, the GNU Compiler Collection (base package)
ii  gcc-10-base:i386  10.2.0-5 
 i386 GCC, the GNU Compiler Collection (base package)
ii  gcc-10-cross-base 10.2.0-3cross2 
 all  GCC, the GNU Compiler Collection (library base package)
ii  gcc-10-i686-linux-gnu 10.2.0-3cross2 
 amd64GNU C compiler (cross compiler for i386 architecture)
ii  gcc-10-i686-linux-gnu-base:amd64  10.2.0-3cross2 
 amd64GCC, the GNU Compiler Collection (base package)
ii  gcc-10-multilib-i686-linux-gnu10.2.0-3cross2 
 amd64GNU C compiler (multilib support) (cross compiler for 
i386 architecture)
ii  gcc-i686-linux-gnu4:10.1.0-1 
 amd64GNU C compiler for the i386 architecture
ii  gcc-multilib-i686-linux-gnu   4:10.1.0-1 
 amd64GNU C compiler for the i386 architecture
ii  lib32gcc-s1   10.2.0-5 
 amd64GCC support library (32 bit Version)
ii  lib64gcc-10-dev-i386-cross10.2.0-3cross2 
 all  GCC support library (64bit development files)
ii  lib64gcc-s1-i386-cross10.2.0-3cross2 
 all  GCC support library (i386) (64bit)
ii  libgcc-10-dev:amd64   10.2.0-5 
 amd64GCC support library (development files)
ii  libgcc-10-dev-i386-cross  10.2.0-3cross2 
 all  GCC support library (development files)
ii  libgcc-s1:amd64   10.2.0-5 
 amd64GCC support library
ii  libgcc-s1:i38610.2.0-5 
 i386 GCC support library
ii  libgcc-s1-i386-cross  10.2.0-3cross2 
 all  GCC support library (i386)
ii  libx32gcc-10-dev-i386-cross   10.2.0-3cross2 
 all  GCC support library (x32 development files)
ii  libx32gcc-s1-i386-cross   10.2.0-3cross2 
 all  GCC support library (i386) (x32)

Bug#961501: remmina is calling home for update notifications

[Andre Heider]

On Wed, 27 May 2020 08:51:40 +0200 Antenore Gatta 
 wrote:

Hi all,

patch is on its way.

Progress can be tracked on our gitlab [0]

Any feedback is much appreciated as it'll easy the resolution of the bug.

Thanks!

Kind regards
Antenore

- [0] https://gitlab.com/Remmina/Remmina/-/merge_requests/2066


Thanks for this, I came here to look specifically for a fix for those 
annoying popups. Glad to see this resolved for the next version!

Bug#952417: Fix importing issues due to using the wrong tmp directory

[Andre Heider]

Source: redmine
Version: 4.0.4-3~bpo10+1
Tags: patch

The debian package ships redmine in /usr/share/redmine and sets up
instances in /var/lib/redmine.

Without this change the issue importer attempts to create a directory in
the read-only /usr tree:
Completed 500 Internal Server Error
Errno::EACCES (Permission denied @ dir_s_mkdir - /usr/share/redmine/tmp):

Now it uses the intended tmp directory and issues can be imported again:
/var/lib/redmine/default/tmp/imports/350548aee641641463bc89cd6043738c
>From ee9b172effe5ffc64a15f84b393923d6fb66d99b Mon Sep 17 00:00:00 2001
From: Andre Heider 
Date: Sun, 23 Feb 2020 16:50:58 +0100
Subject: [PATCH] Fix importing issues due to using the wrong tmp directory

The debian package ships redmine in /usr/share/redmine and sets up
instances in /var/lib/redmine.

Without this change the issue importer attempts to create a directory in
the read-only /usr tree:
Completed 500 Internal Server Error
Errno::EACCES (Permission denied @ dir_s_mkdir - /usr/share/redmine/tmp):

Now it uses the intended tmp directory and issues can be imported again:
/var/lib/redmine/default/tmp/imports/350548aee641641463bc89cd6043738c
---
 app/models/import.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/models/import.rb b/app/models/import.rb
index 7f2715bdb..3efdea53b 100644
--- a/app/models/import.rb
+++ b/app/models/import.rb
@@ -103,7 +103,7 @@ class Import < ActiveRecord::Base
   # It is stored in tmp/imports with a random hex as filename
   def filepath
 if filename.present? && /\A[0-9a-f]+\z/.match?(filename)
-  File.join(Rails.root, "tmp", "imports", filename)
+  File.join(Redmine.root, "tmp", "imports", filename)
 else
   nil
 end
-- 
2.25.0

Bug#939986: (no subject)

[Andre Heider]

Reported upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=205005

Bug#939986: (no subject)

[Andre Heider]

salsa is down, but assuming net/wireless/nl80211.c is unpatched, it's 
running into this:


/* a self-managed-reg device must have a private regdom */
if (WARN_ON(!regdom && self_managed)) {
nlmsg_free(msg);
return -EINVAL;
}

Any ideas?

Bug#939986: (no subject)

[Andre Heider]

previous post was with 5.3~rc5-1~exp2, so it happens there too.
with 5.2.0-2-amd64 it's the same though:

[3.938929] [ cut here ]
[3.938979] WARNING: CPU: 1 PID: 551 at net/wireless/nl80211.c:6859 
nl80211_get_reg_do+0x1fc/0x210 [cfg80211]
[3.938980] Modules linked in: cmac bnep intel_rapl 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass 
crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic ghash_clmulni_intel ledtrig_audio binfmt_misc arc4 
nls_ascii btusb nls_cp437 btrtl btbcm btintel vfat bluetooth fat 
snd_soc_skl iwlmvm i915 snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp 
snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi mac80211 
snd_soc_core snd_compress aesni_intel snd_hda_intel snd_hda_codec 
iwlwifi aes_x86_64 uvcvideo crypto_simd snd_hda_core cryptd drbg 
glue_helper rtsx_usb_ms videobuf2_vmalloc drm_kms_helper snd_hwdep 
videobuf2_memops videobuf2_v4l2 intel_cstate videobuf2_common snd_pcm 
intel_uncore memstick ansi_cprng videodev drm cfg80211 efi_pstore 
intel_rapl_perf snd_timer ecdh_generic ecc iTCO_wdt iTCO_vendor_support 
media sg watchdog evdev joydev i2c_algo_bit intel_pch_thermal snd 
soundcore ideapad_laptop sparse_keymap serio_raw efivars pcspkr
[3.939007]  intel_wmi_thunderbolt rfkill battery pcc_cpufreq 
acpi_pad ac button sunrpc efivarfs ip_tables x_tables autofs4 ext4 
rtsx_usb_sdmmc mmc_core crc16 rtsx_usb mbcache mfd_core jbd2 
crc32c_generic sr_mod cdrom sd_mod xhci_pci xhci_hcd ahci libahci libata 
crc32c_intel psmouse usbcore r8169 scsi_mod realtek libphy i2c_i801 
usb_common wmi video
[3.939023] CPU: 1 PID: 551 Comm: wpa_supplicant Tainted: GW 
   5.2.0-2-amd64 #1 Debian 5.2.9-2
[3.939024] Hardware name: LENOVO 80RJ/Lenovo B71-80, BIOS 0RCN35WW 
12/03/2015

[3.939043] RIP: 0010:nl80211_get_reg_do+0x1fc/0x210 [cfg80211]
[3.939045] Code: ff 48 89 ef e8 c5 a5 2d de b8 a6 ff ff ff eb 89 eb 
ef b8 97 ff ff ff eb 80 e8 70 04 d7 dd 48 c7 c7 08 18 95 c0 e8 b2 81 dd 
dd <0f> 0b 48 89 ef e8 9a a5 2d de b8 ea ff ff ff e9 5b ff ff ff 0f 1f

[3.939046] RSP: 0018:a59781dc3ac8 EFLAGS: 00010246
[3.939047] RAX: 0024 RBX:  RCX: 

[3.939048] RDX:  RSI: 9a7ba2297688 RDI: 
9a7ba2297688
[3.939049] RBP: 9a7b9e5f4a00 R08: 0364 R09: 
0004
[3.939050] R10:  R11: 0001 R12: 
a59781dc3b50
[3.939051] R13: 9a7b9e07f014 R14: 0001 R15: 
9a7b9d7a4300
[3.939052] FS:  7fb70bc70800() GS:9a7ba228() 
knlGS:

[3.939053] CS:  0010 DS:  ES:  CR0: 80050033
[3.939054] CR2: 55f02b69a038 CR3: 0004596bc005 CR4: 
003606e0

[3.939055] Call Trace:
[3.939060]  ? _cond_resched+0x15/0x30
[3.939064]  genl_family_rcv_msg+0x1d2/0x410
[3.939067]  ? __alloc_pages_nodemask+0x163/0x310
[3.939069]  genl_rcv_msg+0x47/0x8c
[3.939071]  ? __kmalloc_node_track_caller+0x1cb/0x290
[3.939073]  ? genl_family_rcv_msg+0x410/0x410
[3.939074]  netlink_rcv_skb+0x49/0x110
[3.939076]  genl_rcv+0x24/0x40
[3.939077]  netlink_unicast+0x17e/0x200
[3.939079]  netlink_sendmsg+0x204/0x3d0
[3.939082]  sock_sendmsg+0x4c/0x50
[3.939084]  ___sys_sendmsg+0x29f/0x300
[3.939085]  ? ___sys_recvmsg+0x16c/0x200
[3.939088]  ? mem_cgroup_commit_charge+0x80/0x4d0
[3.939089]  ? mem_cgroup_try_charge+0x86/0x190
[3.939092]  ? __handle_mm_fault+0xa98/0x1280
[3.939094]  __sys_sendmsg+0x57/0xa0
[3.939097]  do_syscall_64+0x53/0x130
[3.939099]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[3.939101] RIP: 0033:0x7fb70bfc2744
[3.939102] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 
80 00 00 00 00 48 8d 05 99 3c 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 
05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
[3.939103] RSP: 002b:7fff96501ff8 EFLAGS: 0246 ORIG_RAX: 
002e
[3.939105] RAX: ffda RBX: 55f02b663480 RCX: 
7fb70bfc2744
[3.939106] RDX:  RSI: 7fff96502030 RDI: 
0004
[3.939106] RBP: 55f02b693f00 R08: 0004 R09: 
55f02b697dc0
[3.939107] R10: 7fff96502104 R11: 0246 R12: 
55f02b663390
[3.939108] R13: 7fff96502030 R14: 7fff96502160 R15: 
7fff96502104

[3.939110] ---[ end trace 260d0e5afec60bed ]---

Bug#939986: (no subject)

[Andre Heider]

reopen 939986

I get the very same crash :(

[3.877660] [ cut here ]
[3.877711] WARNING: CPU: 1 PID: 551 at net/wireless/nl80211.c:6865 
nl80211_get_reg_do+0x1fc/0x210 [cfg80211]
[3.877712] Modules linked in: cmac bnep intel_rapl_msr 
intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi 
ghash_clmulni_intel snd_hda_codec_conexant snd_hda_codec_generic 
ledtrig_audio snd_soc_skl binfmt_misc iwlmvm snd_soc_skl_ipc 
snd_soc_sst_ipc btusb snd_soc_sst_dsp btrtl btbcm snd_hda_ext_core 
btintel nls_ascii nls_cp437 uvcvideo snd_soc_acpi_intel_match mac80211 
videobuf2_vmalloc bluetooth vfat videobuf2_memops aesni_intel 
snd_soc_acpi i915 fat libarc4 videobuf2_v4l2 aes_x86_64 crypto_simd 
snd_soc_core snd_compress cryptd glue_helper snd_hda_intel iwlwifi 
intel_cstate videobuf2_common snd_hda_codec drbg drm_kms_helper 
efi_pstore videodev snd_hda_core intel_uncore snd_hwdep mc ansi_cprng 
drm cfg80211 snd_pcm intel_rapl_perf rtsx_usb_ms memstick snd_timer 
iTCO_wdt iTCO_vendor_support evdev snd ecdh_generic joydev sg pcspkr 
watchdog serio_raw ecc efivars intel_wmi_thunderbolt intel_pch_thermal
[3.877740]  soundcore i2c_algo_bit ideapad_laptop sparse_keymap 
rfkill battery acpi_pad ac button sunrpc efivarfs ip_tables x_tables 
autofs4 rtsx_usb_sdmmc mmc_core ext4 rtsx_usb mfd_core crc16 mbcache 
jbd2 crc32c_generic sr_mod cdrom sd_mod xhci_pci xhci_hcd ahci libahci 
libata r8169 usbcore crc32c_intel realtek libphy scsi_mod psmouse 
usb_common i2c_i801 wmi video
[3.877758] CPU: 1 PID: 551 Comm: wpa_supplicant Tainted: GW 
   5.3.0-rc5-amd64 #1 Debian 5.3~rc5-1~exp2
[3.877759] Hardware name: LENOVO 80RJ/Lenovo B71-80, BIOS 0RCN35WW 
12/03/2015

[3.89] RIP: 0010:nl80211_get_reg_do+0x1fc/0x210 [cfg80211]
[3.877780] Code: ff 48 89 ef e8 75 d6 86 fb b8 a6 ff ff ff eb 89 eb 
ef b8 97 ff ff ff eb 80 e8 30 71 2f fb 48 c7 c7 a8 b8 7c c0 e8 52 ee 35 
fb <0f> 0b 48 89 ef e8 4a d6 86 fb b8 ea ff ff ff e9 5b ff ff ff 0f 1f

[3.877781] RSP: 0018:b22d0051bac0 EFLAGS: 00010246
[3.877783] RAX: 0024 RBX:  RCX: 

[3.877784] RDX:  RSI: 8a2762297688 RDI: 
8a2762297688
[3.877785] RBP: 8a2759715f00 R08: 0364 R09: 
0004
[3.877785] R10:  R11: 0001 R12: 
b22d0051bb48
[3.877786] R13: 8a2759b02014 R14: 0001 R15: 
8a275a6d0300
[3.877788] FS:  7f47d4411800() GS:8a276228() 
knlGS:

[3.877789] CS:  0010 DS:  ES:  CR0: 80050033
[3.877790] CR2: 5645fc5b4038 CR3: 00045a4e0005 CR4: 
003606e0

[3.877791] Call Trace:
[3.877796]  ? _cond_resched+0x15/0x30
[3.877800]  genl_family_rcv_msg+0x1d2/0x410
[3.877803]  ? __alloc_pages_nodemask+0x163/0x310
[3.877806]  genl_rcv_msg+0x47/0x90
[3.877808]  ? __kmalloc_node_track_caller+0x1b5/0x2f0
[3.877810]  ? genl_family_rcv_msg+0x410/0x410
[3.877812]  netlink_rcv_skb+0x49/0x110
[3.877815]  genl_rcv+0x24/0x40
[3.877816]  netlink_unicast+0x17e/0x200
[3.877819]  netlink_sendmsg+0x210/0x3d0
[3.877822]  sock_sendmsg+0x5b/0x60
[3.877824]  ___sys_sendmsg+0x29f/0x320
[3.877826]  ? ___sys_recvmsg+0x16c/0x200
[3.877829]  ? mem_cgroup_commit_charge+0x61/0x4c0
[3.877831]  ? mem_cgroup_try_charge+0x6a/0x190
[3.877833]  ? __handle_mm_fault+0xa92/0x1280
[3.877836]  ? __cgroup_bpf_run_filter_setsockopt+0xba/0x2e0
[3.877837]  __sys_sendmsg+0x57/0xa0
[3.877841]  do_syscall_64+0x53/0x130
[3.877844]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[3.877846] RIP: 0033:0x7f47d4763744
[3.877847] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 
80 00 00 00 00 48 8d 05 99 3c 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 
05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
[3.877848] RSP: 002b:7fff1c3915d8 EFLAGS: 0246 ORIG_RAX: 
002e
[3.877850] RAX: ffda RBX: 5645fc57d480 RCX: 
7f47d4763744
[3.877851] RDX:  RSI: 7fff1c391610 RDI: 
0004
[3.877851] RBP: 5645fc5adf00 R08: 0004 R09: 
5645fc5b1dc0
[3.877852] R10: 7fff1c3916e4 R11: 0246 R12: 
5645fc57d390
[3.877853] R13: 7fff1c391610 R14: 7fff1c391740 R15: 
7fff1c3916e4

[3.877858] ---[ end trace 3f3d716d44a8ac03 ]---

Bug#917939: please enable CONFIG_ARM_ARMADA_37XX_CPUFREQ for arm64

[Andre Heider]

On Sat, 19 Jan 2019 17:04:43 +0900 Hideki Yamane 
 wrote:

Hi,

On Tue, 1 Jan 2019 10:27:00 +0100 Andre Heider  wrote:
> Source: linux
> Version: 4.19.12-1
> Severity: wishlist
> 
> Hi,
> 
> this option is missing for cpu frequency scaling on e.g. my espressobin.


 arch/arm64/configs/defconfig seems to have it in 4.19.12-1 to me.

$ grep CONFIG_ARM_ARMADA_37XX_CPUFREQ -r ./
./arch/arm64/configs/defconfig:CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
./drivers/cpufreq/Makefile:obj-$(CONFIG_ARM_ARMADA_37XX_CPUFREQ)+= 
armada-37xx-cpufreq.o


Yes, that's the upstream defconfig, it's just missing for Debian.

Could we please get that option? Pretty please? :)

Bug#919863: RFP: gallium-nine-standalone: A standalone version of Gallium Nine

[Andre Heider]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-w...@lists.debian.org

* Package name: gallium-nine-standalone
  Version : 0.1
  Upstream Author : Andre Heider 
* URL : https://github.com/dhewg/nine
* License : LGPL-2.1+
  Programming Lang: C
  Description : A standalone version of Gallium Nine

Gallium Nine Standalone, as the name implies, is a standalone version of 
the WINE parts of Gallium Nine.


This decouples Gallium Nine from the WINE tree, so that it can be used 
with any WINE version. There is no need for any WINE patches. A stable, 
development, or staging WINE release is sufficient.

Bug#917939: please enable CONFIG_ARM_ARMADA_37XX_CPUFREQ for arm64

[Andre Heider]

Source: linux
Version: 4.19.12-1
Severity: wishlist

Hi,

this option is missing for cpu frequency scaling on e.g. my espressobin.

According to [0], 4.19 should be ready for cpufreq on this platform. The 
mentioned AVS support doesn't seem to have an additional config knob, or 
at least I didn't see one.



[0] https://elinux.org/Marvell_EBU:Mainline_Linux

Thanks!
Andre

Bug#916055: (no subject)

[Andre Heider]

On 14/12/2018 15:10, Martín Ferrari wrote:

On 14/12/2018 05:43, Andre Heider wrote:

I ran into the same issue and came with another approach. The patch was
just merged upstream[0], so post v0.17.0.

That also introduces a new metric if a disk is in standby mode.


Thanks Andre! I have replaced my patch with yours and uploaded.


Nice, works as intended ;) Thanks!

Bug#916055: (no subject)

[Andre Heider]

I ran into the same issue and came with another approach. The patch was 
just merged upstream[0], so post v0.17.0.


That also introduces a new metric if a disk is in standby mode.

Could you please update to 0.17.0 and cherry-pick that instead?

Thanks!
Andre

[0] 
https://github.com/prometheus/node_exporter/commit/7c960fd68365e9bbdb14cf140fc1d26d4c27333a.patch

Bug#914031: (no subject)

[Andre Heider]

The first issue is fixed upstream [0] and is part of the just release v3.21.
The patch to fix the second [1] was rejected though.

Which means this can be closed.

[0] 
https://source.winehq.org/git/wine.git/commitdiff/2dfff7e63c4fc6f97e83df448a2c2b8c4b9eedd5

[1] https://www.winehq.org/pipermail/wine-devel/2018-November/135680.html

Bug#914031: (no subject)

[Andre Heider]

Hang on, I whipped up a patch which attempts to solve that library path 
issue in a universal way. Sent upsteam, let's see how that goes

Bug#914031: winegcc-development breaks due to non-standard paths

[Andre Heider]

Package: wine-development
Version: 3.20-2
Tags: patch

Fix two issues specific to the wine-development package:

1) Fix locating libwine.so and hence the correct library path for
   cross-compiling. Using the 64bit -tools package breaks linking
   32bit binaries [0][1] because winegcc fails to find its 32bit
   libraries, and it incorrectly falls back to the native ones.

2) While at it, make winegcc use `winebuild-development` per default,
   so the workaround script /usr/bin/winegcc-development can be removed.
   The envvar WINEBUILD can still be used to override this.

[0] echo 'int main() { return 0; }' | winegcc-development -m32 -x -
[1] ld: relocatable linking with relocations from format elf64-x86-64 
(/usr/lib/x86_64-linux-gnu/wine-development/libwinecrt0.a(exe_entry.o)) 
to format elf32-i386 (a.gjlTmQ.o) is not supported


Attached patch fixes both issues, please consider applying it!

Thanks!
Andre
>From 44ef6582ef3c3628bccac8d9bf10db6609feb439 Mon Sep 17 00:00:00 2001
From: Andre Heider 
Date: Fri, 16 Nov 2018 23:14:08 +0100
Subject: [PATCH] winegcc: fixups for wine-development non-standard paths

Fix two issues specific to the wine-development package:

1) Fix locating libwine.so and hence the correct library path for
   cross-compiling. Using the 64bit -tools package breaks linking
   32bit binaries [0][1] because winegcc fails to find its 32bit
   libraries, and it incorrectly falls back to the native ones.

2) While at it, make winegcc use `winebuild-development` per default,
   so the workaround script /usr/bin/winegcc-development can be removed.
   The envvar WINEBUILD can still be used to override this.

[0] echo 'int main() { return 0; }' | winegcc-development -m32 -x -
[1] ld: relocatable linking with relocations from format elf64-x86-64 (/usr/lib/x86_64-linux-gnu/wine-development/libwinecrt0.a(exe_entry.o)) to format elf32-i386 (a.gjlTmQ.o) is not supported

Signed-off-by: Andre Heider 
---
 tools/winegcc/winegcc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/winegcc/winegcc.c b/tools/winegcc/winegcc.c
index 6b3b4b6aab..39bd6b69a2 100644
--- a/tools/winegcc/winegcc.c
+++ b/tools/winegcc/winegcc.c
@@ -456,7 +456,7 @@ static char *get_lib_dir( struct options *opts )
 
 for (i = 0; i < sizeof(stdlibpath)/sizeof(stdlibpath[0]); i++)
 {
-char *p, *buffer = xmalloc( strlen(stdlibpath[i]) + strlen("/arm-linux-gnueabi") + strlen(libwine) + 1 );
+char *p, *buffer = xmalloc( strlen(stdlibpath[i]) + strlen("/arm-linux-gnueabi") + strlen("/wine-development") + strlen(libwine) + 1 );
 strcpy( buffer, stdlibpath[i] );
 p = buffer + strlen(buffer);
 while (p > buffer && p[-1] == '/') p--;
@@ -481,6 +481,7 @@ static char *get_lib_dir( struct options *opts )
 default:
 assert(0);
 }
+strcat( p, "/wine-development" );
 strcat( p, libwine );
 if (check_platform( opts, buffer )) goto found;
 
@@ -711,7 +712,7 @@ static strarray *get_winebuild_args(struct options *opts)
 const char* winebuild = getenv("WINEBUILD");
 strarray *spec_args = strarray_alloc();
 
-if (!winebuild) winebuild = "winebuild";
+if (!winebuild) winebuild = "winebuild-development";
 strarray_add( spec_args, winebuild );
 if (verbose) strarray_add( spec_args, "-v" );
 if (keep_generated) strarray_add( spec_args, "--save-temps" );
-- 
2.19.1

Bug#788040: (no subject)

[Andre Heider]

On 14/09/2018 10:39, Yangfl wrote:

It's currently blocked in NEW queue; see
https://ftp-master.debian.org/new/qtox_1.15.0-1.html


And it seems that's still the case :(

I don't know what's required to get something out of the "new queue", 
but what's holding this up?


Regards,
Andre

Bug#788040: (no subject)

[Andre Heider]

All blocking bugs have been resolved, can we still expect a qtox package?

Bug#888817: arm64: please enable CONFIG_PCI_TEGRA

[Andre Heider]

Source: linux
Version: 4.14.0-3-arm64
Severity: wishlist

Hi,

this is for the tegra pcie controller, as found on e.g. the jetson tx1: 
https://elinux.org/Jetson_TX1


Thanks,
Andre

Bug#884003: FDT overlay support

[Andre Heider]

On 21/01/18 00:52, Vagrant Cascadian wrote:

On 2018-01-20, Vagrant Cascadian wrote:

On 2017-12-12, Andre Heider wrote:

Subject: [PATCH 05/10] bootscr.uboot-generic: support multiple prefixes to
  load from
Subject: [PATCH 06/10] beaglebone: clean up boot script


I might try to rework 5-6 with a slightly different approach.


Merged and pushed these too.


Nice, thanks!


Subject: [PATCH 07/10] Introduce user variable OVERLAYS
Subject: [PATCH 08/10] Add a hook to bootscr.uboot-generic for post fdt
  loading tasks
Subject: [PATCH 09/10] Introduce fdt overlay support
Subject: [PATCH 10/10] beaglebone: enable fdt overlay support


You said you had some changes to make to this, please re-submit the
updated remaining patches against current git master.


Yes, I'll do just that ;)

Regards,
Andre

Bug#886983: arm64: please enable CONFIG_I2C_PXA

[Andre Heider]

Source: linux
Version: 4.14.0-3-arm64
Severity: wishlist

Hi,

this is for the i2c host controller on mvebu, like espressobin.

Thanks,
Andre

Bug#884003: FDT overlay support

[Andre Heider]

Hi Vagrant,

On 20/12/17 22:32, Vagrant Cascadian wrote:

On 2017-12-12, Andre Heider wrote:

I added the ability to concatenate multiple scripts/snippets for the
final boot script.
The new overlay handling snippet is supposed to be
used with this. But the feature itself also allows nice cleanups,
demonstrated on odroid-u3 and beaglebone (and there're quite some more
cleanups possible).


I very much like the idea of this; so many of the boot scripts
copy-and-paste a lot of code between them, which makes maintenence more
difficult as well as implementing features and changes across all the
boot scripts...


Yeah, the copypasta is the first thing I noticed after git cloning. I 
tried to make the overlay support universal. So the less duplication 
there is, the easier it'll get to reuse it.



Unfortunately, I haven't had a chance to do more than a very cursory
glance at your patches yet. Made some comments in-line on some of the
individual patches below.


Thanks for the first glance! There's no need to hurry, especially with 
xmas around the corner.



To test this, you need:
- u-boot with CONFIG_OF_LIBFDT_OVERLAY
- base dtb with symbols (-@)


Would the symbols (-@) be harmful to enable in Debian's kernels by
default?


That's the big question. I looked around and found 3 cases where 
distros/downstreams enable symbols, see [1], [2] and [3]. But those 3 
are in a different boat than debian: It's just per family of SoC.


I'm not sure if anything breaks if debian would enable it for its armhf 
multi platform build. I'm currently trying to find out with a solution 
appropriate for the upstream kernel [4], but I'm not sure if that pans out.



Is it feasible to use dtc to extract the .dts, rebuild it with -@, and
then use that .dtb instead... or does it need more information from the
original device tree(s)?


That's not going to work, without -@ the "__symbols__" node is missing. 
Without that an overlay can not reference e.g. the alias 'spi0'. You 
need the original dts to include these.



- your own overlays, again with symbols, in /boot/dtbs/overlays


Are there some very basic example overlays that would be feasible to just test 
that
this feature is working?

I don't have much experience with overlays, but have a beagleboneblack
and a CHIP that in theory support this, and some devices I can attach
that require overlays...

Will try to test myself sometime in the coming weeks.


Since I used a boneblack too, you can find my basic overlays attached. 
I'm not a device tree expert, so they might not be correct, but they're 
good enough to test this and see the results (especially since commit [5]).



From: Andre Heider <a.hei...@gmail.com>
Date: Tue, 12 Dec 2017 09:23:37 +0100
Subject: [PATCH 01/10] bootscr.uboot-generic: quote bootargs

Signed-off-by: Andre Heider <a.hei...@gmail.com>
---
  bootscript/all/bootscr.uboot-generic | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bootscript/all/bootscr.uboot-generic 
b/bootscript/all/bootscr.uboot-generic
index db4066a..bcf6e96 100644
--- a/bootscript/all/bootscr.uboot-generic
+++ b/bootscript/all/bootscr.uboot-generic
@@ -25,7 +25,7 @@ if test -n "${console}"; then
setenv bootargs "${bootargs} console=${console}"
  fi
  
-setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} @@LINUX_KERNEL_CMDLINE@@

+setenv bootargs "@@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} 
@@LINUX_KERNEL_CMDLINE@@"
  @@UBOOT_ENV_EXTRA@@
  
  if test -z "${fk_kvers}"; then


Why is this needed?


It's not, I did that just to be consistent (see 3 lines above). Patch 
can be dropped if you disagree.



From: Andre Heider <a.hei...@gmail.com>
Date: Tue, 12 Dec 2017 09:25:26 +0100
Subject: [PATCH 05/10] bootscr.uboot-generic: support multiple prefixes to
  load from

Allow custom boot scripts to set $fk_image_locations as a list of
directories to load boot files from.

If unset, $prefix will be the used - which is sufficient for all recent
u-boot versions.

This allows the clean up of various custom boot scripts. Code borrowed
form the sunxi script.

Signed-off-by: Andre Heider <a.hei...@gmail.com>
---
  bootscript/all/bootscr.uboot-generic | 38 +---
  1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/bootscript/all/bootscr.uboot-generic 
b/bootscript/all/bootscr.uboot-generic
index bcf6e96..509efe7 100644
--- a/bootscript/all/bootscr.uboot-generic
+++ b/bootscript/all/bootscr.uboot-generic
@@ -48,14 +48,30 @@ else
setenv partition ${distro_bootpart}
  fi
  
-load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${prefix}vmlinuz-${fk_kvers} \

-&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${prefix}${fdtpath} \
-&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} 
${prefix}initrd.img-${fk_kvers} \
-&& echo "Booting Debian ${fk_kvers} from ${devtype} ${devnum}:${partition}...

Bug#884003: FDT overlay support

[Andre Heider]

The patches need a bit more work.

But before I do that, I'd like some feedback if this would be 
desirable/acceptable at all.


Let me know what you think,
Andre

Bug#884003: FDT overlay support

[Andre Heider]

Attached a patch series with an implementation.

I added the ability to concatenate multiple scripts/snippets for the 
final boot script. The new overlay handling snippet is supposed to be 
used with this. But the feature itself also allows nice cleanups, 
demonstrated on odroid-u3 and beaglebone (and there're quite some more 
cleanups possible).


To test this, you need:
- u-boot with CONFIG_OF_LIBFDT_OVERLAY
- base dtb with symbols (-@)
- your own overlays, again with symbols, in /boot/dtbs/overlays

With e.g. foo.dtb and bar.dtb in /boot/dtbs/overlays you can then set 
either set $fk_overlays on the u-boot prompt or OVERLAYS in 
/etc/defaults/flash-kernel to "foo bar".


Testing on beaglebone looks promising so far ;)
>From efaadbd96967674f2fb82eb530dd447a6b5c65ba Mon Sep 17 00:00:00 2001
From: Andre Heider <a.hei...@gmail.com>
Date: Tue, 12 Dec 2017 09:23:37 +0100
Subject: [PATCH 01/10] bootscr.uboot-generic: quote bootargs

Signed-off-by: Andre Heider <a.hei...@gmail.com>
---
 bootscript/all/bootscr.uboot-generic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bootscript/all/bootscr.uboot-generic b/bootscript/all/bootscr.uboot-generic
index db4066a..bcf6e96 100644
--- a/bootscript/all/bootscr.uboot-generic
+++ b/bootscript/all/bootscr.uboot-generic
@@ -25,7 +25,7 @@ if test -n "${console}"; then
   setenv bootargs "${bootargs} console=${console}"
 fi
 
-setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} @@LINUX_KERNEL_CMDLINE@@
+setenv bootargs "@@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} @@LINUX_KERNEL_CMDLINE@@"
 @@UBOOT_ENV_EXTRA@@
 
 if test -z "${fk_kvers}"; then
-- 
2.15.1

>From 8f3c0450c778901ba93a8dd8a918820f92d662d5 Mon Sep 17 00:00:00 2001
From: Andre Heider <a.hei...@gmail.com>
Date: Tue, 12 Dec 2017 08:16:26 +0100
Subject: [PATCH 02/10] Allow compiling scripts from $tmpdir

Append a suffix to the temporary file to ensure source != target

Signed-off-by: Andre Heider <a.hei...@gmail.com>
---
 functions | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/functions b/functions
index b2ae5be..ad53277 100644
--- a/functions
+++ b/functions
@@ -456,7 +456,7 @@ mkimage_script() {
 	local sdata="$3"
 	local script="$4"
 
-	local tdata="$tmpdir/$(basename $sdata)"
+	local tdata="$tmpdir/$(basename $sdata).out"
 
 	local ubootenv="$(mktemp --tmpdir=$tmpdir)"
 	gen_ubootenv > $ubootenv
-- 
2.15.1

>From 8dd287741e23ea06c6a8e480ab1f24689d36bf9b Mon Sep 17 00:00:00 2001
From: Andre Heider <a.hei...@gmail.com>
Date: Tue, 12 Dec 2017 08:18:12 +0100
Subject: [PATCH 03/10] Add support for multiple scripts sources

Allow multiple entries in 'U-Boot-Script-Name' and concatenate them
as the final boot script.

Signed-off-by: Andre Heider <a.hei...@gmail.com>
---
 functions | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/functions b/functions
index ad53277..885413e 100644
--- a/functions
+++ b/functions
@@ -948,7 +948,11 @@ case "$method" in
 		fi
 		if [ -n "$boot_script_path" ]; then
 			boot_script_path="$boot_mnt_dir/$boot_script_path"
-			boot_script="$BOOTSCRIPTS_DIR/$usname"
+			boot_script="$tmpdir/bootscript"
+			for script in $usname ; do
+echo "\n#\n# flash-kernel: $script\n#\n" >> "$boot_script"
+cat "$BOOTSCRIPTS_DIR/$script" >> "$boot_script"
+			done
 			mkimage_script "$usaddr" "boot script" "$boot_script" \
 "$tmpdir/boot.scr"
 			boot_script="$tmpdir/boot.scr"
-- 
2.15.1

>From 132dfdeb0e9a5a396ee543ee1386cb750929846f Mon Sep 17 00:00:00 2001
From: Andre Heider <a.hei...@gmail.com>
Date: Tue, 12 Dec 2017 09:12:28 +0100
Subject: [PATCH 04/10] odroid-u3: clean up boot script

bootscr.odroid first sets some compatibility variables and then contains
a full copy of bootscr.uboot-generic.

Get rid of the copy and use the multiple scripts feature instead. This
results in the very same boot script.

Signed-off-by: Andre Heider <a.hei...@gmail.com>
---
 bootscript/armhf/bootscr.odroid | 63 -
 db/all.db   |  2 +-
 2 files changed, 1 insertion(+), 64 deletions(-)

diff --git a/bootscript/armhf/bootscr.odroid b/bootscript/armhf/bootscr.odroid
index b66aafc..7a46f6c 100644
--- a/bootscript/armhf/bootscr.odroid
+++ b/bootscript/armhf/bootscr.odroid
@@ -18,66 +18,3 @@ fi
 if test -z "${ramdisk_addr_r}" ; then
   setenv ramdisk_addr_r ${initrdaddr}
 fi
-
-# Bootscript using the new unified bootcmd handling
-# introduced with u-boot v2014.10, and patched into
-# the debian odroid target since 2016.03+dfsg1-5.
-#
-# Expects to be called with the following environment variables set:
-#
-#  devtype  e.g. mmc/scsi etc
-#  d

Bug#884003: FDT overlay support

[Andre Heider]

Source: flash-kernel
Severity: wishlist

Recent u-boot versions support fdt overlays. It can load a base dtb, 
apply various overlays to it, and pass the final device tree to the kernel.


To be able to use such overlays:
1) u-boot has to be compiled with CONFIG_OF_LIBFDT_OVERLAY
2) the base dtb has to be compiled with "-@" / "--symbols"
3) all overlays have to be compiled with "-@" / "--symbols"

1: already given for debian's u-boot for ti's beagle bone black, which 
is what I tested this on

2: not the default for the kernel dtb files, I used [1] as a quick hack
3: this should just be the user's responsibility for now (until there's 
a centralized repository or something debian could just package)


With the quick boot script [2] I can then successfully boot 
debian's kernel with applied overlays of my choosing.


That's great, especially since it's way to painful to just enable basic 
stuff like spi. Now we "just" need a way for flash-kernel to support it ;)


One way could be:
- overlays need to be in /boot/dtbs/overlays
- user sets a list of overlays in /etc/defaults/flash-kernel
  like "OVERLAYS=am335x-bone-black-disable-video 
am335x-bone-black-disable-audio am335x-bone-black-spidev0 
am335x-bone-black-spidev1"

- flash-kernel passes the list of overlays to it's u-boot boot script
- the boot script loads and applies all requested overlays

[1]
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 04b5633df1cf..e339d40c02d1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -308,7 +308,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb
 quiet_cmd_dtc = DTC $@
 cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
$(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
-   $(DTC) -O dtb -o $@ -b 0 \
+   $(DTC) -@ -O dtb -o $@ -b 0 \
$(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)

[2]
load mmc 1 $fdt_addr_r am335x-boneblack.dtb
fdt addr $fdt_addr_r
fdt resize 8192
load mmc 1 $ramdisk_addr_r am335x-bone-black-disable-video.dtb
fdt apply $ramdisk_addr_r
load mmc 1 $ramdisk_addr_r am335x-bone-black-disable-audio.dtb
fdt apply $ramdisk_addr_r
load mmc 1 $ramdisk_addr_r am335x-bone-black-spidev0.dtb
fdt apply $ramdisk_addr_r
load mmc 1 $ramdisk_addr_r am335x-bone-black-spidev1.dtb
fdt apply $ramdisk_addr_r
...

Bug#883908: missing dependencies

[Andre Heider]

Package: libbluray-dev
Version: 1:1.0.2-1

the -dev packages needs to depend on other -dev packages:

pkg-config libbluray --cflags
Package libxml-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxml-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libxml-2.0', required by 'libbluray', not found

pkg-config libbluray --cflags
Package fontconfig was not found in the pkg-config search path.
Perhaps you should add the directory containing `fontconfig.pc'
to the PKG_CONFIG_PATH environment variable
Package 'fontconfig', required by 'libbluray', not found

and probably libfreetype6-dev, although libfontconfig1-dev already 
depends on it

Bug#883853: Please provide binaries/symlinks without version suffix

[Andre Heider]

Source: gcc-7-cross

(this applies to gcc-*-cross, I was unsure where to file it)

Currently all the binaries of all -cross packages have a version suffix.

For gcc it looks like this:
gcc-7-aarch64-linux-gnu: /usr/bin/aarch64-linux-gnu-gcc-7
gcc-5-aarch64-linux-gnu: /usr/bin/aarch64-linux-gnu-gcc-5

gcc-aarch64-linux-gnu then provides symlinks to the current default version:
/usr/bin/aarch64-linux-gnu-gcc -> aarch64-linux-gnu-gcc-7

Now, most build environments provide a way to set a prefix for the 
toolchain to use. Like the kernel:

CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- make something

That works fine for debian's default gcc version, but doesn't when you 
want to use another version. While some build environments allow a way 
to set a suffix too, they generally do not. Setting just a prefix seems 
like the established way.


A dedicated directory with binaries/symlinks without version suffix 
would fix this, like:

CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-5/aarch64-linux-gnu-

Please consider providing it!

Thanks,
Andre

Bug#883580: debian-installer: arm64: please ship dtb files

[Andre Heider]

On Tue, 5 Dec 2017 14:07:46 + Leif Lindholm 
 wrote:

Please don't ship dtb files at all, including the kernel images.

If firmware does not come with hardware description, that is a
shortcoming of the firmware. If a newer kernel cannot be booted with
an existing device tree, then that is a bug and the kernel should be
patched.


Ok, so in your world a distribution should not ship any dtb files, 
because the manufacturer's firmware is bug-free and feature complete on 
day one.


That's nice, but doesn't sound like the real world at all.

> By all means, put a tree of verified actually working device trees
> somewhere for platforms known to be provided with bad versions from
> their manufacturer.

That tree is the sum of the dtb files of the corresponding kernel, which 
this bug report is about. Those may not adhere to your definition of 
verified, but please don't forget that there're two separate worlds out 
there: upstream and downstream. Debian's current way of booting a kernel 
release with its dtb ensures those world never collide, and I think that 
is a very wise choice.


I don't know what devices you work on, but I have a couple of different 
consumer armhf and arm64 devices, spread out over different 
architectures. All their device trees are updated every single kernel 
release. Often it's for new drivers like mmc, pci, net, dri etc., which 
obviously the installer could make use of. Bindings are merged with the 
driver, so of course I want the dtb matching its kernel!

Bug#883580: debian-installer: arm64: please ship dtb files

[Andre Heider]

Source: debian-installer

Some arm64 devices (like espressobin) boot using u-boot and not using 
efi. For these the kernel's corresponding dtb is required to boot.


I only checked the latest daily netboot.tar.gz, and while armhf ships 
those files, arm64 does not.


When fishing out the dtb out of the binary kernel package and using that 
for netboot, the installer works just fine - including its flash-kernel 
run, which makes the freshly installed system bootable using dtb.

Bug#879903: login: Add ttyMV0 to /etc/securetty

[Andre Heider]

seconded, this is the serial device used by marvell armada 37xx devices, 
see drivers/tty/serial/mvebu-uart.c


debian-installer adds it, but a debootstrapped root obviously does not:

Thanks,
Andre

$ tail /etc/securetty
# serial console added by debian-installer
ttyMV0

Bug#869028: linux-image-4.12.0-trunk: Please enable CONFIG_IOSCHED_BFQ

[Andre Heider]

Source: linux
Version: 4.12.0-trunk
Severity: wishlist

Hi,

new blq-mq i/o scheduler in 4.12, please enable.

Thanks,
Andre

Bug#826045: systemd: New kernels are not booted

[Andre Heider]

Just as a reference, maybe it's of some use to others:

I'm using the attached scripts as:
/etc/kernel/postinst.d/zz-systemd-bootd
/etc/kernel/postrm.d/zz-systemd-bootd

They're very basic, but worked for me just fine for the kernel updates 
of the past +2 month.


That's the kind of distribution<->systemd-bootd integration I was 
looking for,


Regards,
Andre
#!/bin/sh -e

version="$1"
kernel=/boot/vmlinuz-"${version}"

[ -x /usr/bin/kernel-install ] || exit 0

# passing the kernel version is required
if [ -z "${version}" ]; then
echo >&2 "W: systemd-bootd: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} 
did not pass a version number"
exit 2
fi

# absolute file name of kernel image may be passed as a second argument
if [ -n "$2" ]; then
kernel="$2"
fi

# avoid running multiple times
if [ -n "$DEB_MAINT_PARAMS" ]; then
eval set -- "$DEB_MAINT_PARAMS"
if [ -z "$1" ] || [ "$1" != "configure" ]; then
exit 0
fi
fi

echo >&2 "I: systemd-bootd: installing kernel ${kernel}"
kernel-install add "${version}" "${kernel}"
#!/bin/sh -e

version="$1"

[ -x /usr/bin/kernel-install ] || exit 0

# passing the kernel version is required
if [ -z "${version}" ]; then
echo >&2 "W: systemd-bootd: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} 
did not pass a version number"
exit 0
fi

# avoid running multiple times
if [ -n "$DEB_MAINT_PARAMS" ]; then
eval set -- "$DEB_MAINT_PARAMS"
if [ -z "$1" ] || [ "$1" != "remove" ]; then
exit 0
fi
fi

echo >&2 "I: systemd-bootd: removing kernel ${version}"
kernel-install remove "${version}"

Bug#854814: Fails to start systemd-resolved

[Andre Heider]

On Sat, 11 Feb 2017 17:17:20 +0100 Martin Pitt <mp...@debian.org> wrote:

No, I did test it with our current systemd package and it worked. However, I
apparently only tested it with resolvconf installed, but not without
resolvconf. Trivial fix, pushed:

  https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=030866cf7d3

Sorry for the trouble!


confirming fix as working, thanks!

--
Mit freundlichen Grüßen,
Andre Heider
Heider Softwareentwicklung

+49 5121 / 9289068
http://back-control.de
a.hei...@back-control.de

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese 
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den 
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie 
die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist 
nicht gestattet.

Bug#828414: libtorrent: a couple of fixes, build with OpenSSL 1.1

[Andre Heider]

Thanks Peter, I can confirm your whole patchset compiles and works for
me just fine on armhf!

Bug#826045: systemd: New kernels are not booted

[Andre Heider]

On Mon, Dec 5, 2016 at 3:39 PM, Julian Andres Klode  wrote:
> Yes. Well, not missing, but rather left out by purpose. systemd
> can't just start installing bootloader _integration_, that would
> be weird.

I'm not sure I follow.

What I'm looking for is just the same basic integration for debian as
gummiboot once had.

Of course the missing scripts I mentioned cannot blindly call
kernel-install, they'll have to check if systemd-bootd is
installed/used and bail out accordingly. It doesn't make much sense
otherwise. Is that what you mean? With that in mind I don't see why
systemd shouldn't do boot loader integration, all the pieces are
already there.

Regards,
Andre

Bug#826045: systemd: New kernels are not booted

[Andre Heider]

Hi,

I just ran into this again and had a look around:
The systemd tool kernel-install(8) is already installed and appears to
be working just fine.

It's "add" mode copies debian's kernel/initrd to the esp and adds a
boot loader entry, which boots just fine.
It's "remove" mode cleans up the copied/created files from the "add" mode.

It appears there're just a few trivial /etc/kernel/?.d wrapper scripts missing?

Regards,
Andre

Bug#836255: DTBs are no longer bundled

[Andre Heider]

Source: linux
Version: 4.7.0-1-armmp-lpae
Severity: important

Hi,

starting with 4.7 the DTBs are not part of the package anymore:

# dpkg -L linux-image-4.5.0-2-armmp-lpae|grep dtb|wc -l
349
# dpkg -L linux-image-4.6.0-1-armmp-lpae|grep dtb|wc -l
363
# dpkg -L linux-image-4.7.0-1-armmp-lpae|grep dtb|wc -l
0

which in return makes flash-kernel fail, and the kernel can not be
properly booted (on devices depending on flash-kernel).

Bug#823493: Cubieboard2 also affected

[Andre Heider]

Hi,

there's finally a v4.5 fix available, see [0]:

> v4 fixes for 4.5 are here:
>
> https://patchwork.ozlabs.org/patch/598195/ (revert)
> https://patchwork.ozlabs.org/patch/598196/

Those two didn't make it to v4.5.5, but please incude these, stmmac is
broken for 5 debian kernel releases already.

Thanks,
Andre

[0] https://www.spinics.net/lists/netdev/msg369626.html

Bug#818174: Please enable powerplay for amdgpu

[Andre Heider]

Source: linux
Version: 4.5~rc7-1~exp1
Severity: wishlist

Hi,

powerplay is the power management for the amdgpu driver.

On top of the config switch this feature used to be hidden behind an
additional kernel module parameter. As of v4.5 it looks like it's
enabled per default for the families 'tonga' and 'fiji', but need to
be enabled via the kernel cmdline for 'carrizo' and 'stoney', see [0].

Please enable CONFIG_DRM_AMD_POWERPLAY.

Thanks,
Andre

[0] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c?id=refs/tags/v4.5#n95

Bug#808623: Please enable new sunxi drivers

[Andre Heider]

Source: linux
Version: 4.4~rc5-1~exp1
Severity: wishlist

Hi,

4.4 mainline merged new sunxi drivers, two not yet enabled:
* CAN controller (CONFIG_CAN_SUN4I)
* Audio codec (CONFIG_SND_SUN4I_CODEC)

Please enable.

Thanks,
Andre

Bug#808625: Module sun4i-ss fails to load

[Andre Heider]

Source: linux
Version: 4.4~rc5-1~exp1
Severity: bug

Hi,

the new module fails to load:

[   13.879728] sun4i-ss 1c15000.crypto-engine: no reset control found
[   13.887548] sun4i-ss 1c15000.crypto-engine: Die ID 0
[   13.892618] sun4i-ss 1c15000.crypto-engine: Fail to register md5
[   13.898809] sun4i-ss: probe of 1c15000.crypto-engine failed with error -22

There's an upstream bug about it [0], and while the fix didn't yet
land in master nor stable, it is currently found in next [1].

Thanks,
Andre

[0] https://bugzilla.kernel.org/show_bug.cgi?id=107281
[1] 
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=4f9ea86604e3ba64edd2817795798168fbb3c1a6

Bug#808623:

[Andre Heider]

And another driver not yet enabled: "X-Powers AXP20X power button
driver" (CONFIG_INPUT_AXP20X_PEK), which was merged for 4.0 already

Bug#804856: Please enable new sunxi drivers

[Andre Heider]

Source: linux
Version: 4.3-1~exp1
Severity: wishlist

Hi,

4.3 mainline merged new sunxi drivers, two not yet enabled:
* the USB OTG controller (CONFIG_USB_MUSB_SUNXI)
* support for the Security System crypto accelerator
(CONFIG_CRYPTO_DEV_SUN4I_SS)

Please enable.

Thanks,
Andre

Bug#792388:

[Andre Heider]

I noticed the commit, thx Ian!

 I only own a beaglebone black, so not all drivers are of interest
 there, but unless there's a reason not to: please enable.

Hah, I also own a couple of other devices unrelated to sunxi, but what
I really meant is my cubieboard 2 :P


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#792388: Please enable the latest sunxi drivers for armmp(-lpae)

[Andre Heider]

Source: linux
Version: 4.1.2-1~exp1
Severity: wishlist

Hi,

there're a couple of new mainline drivers missing for sunxi:

MTD_NAND_SUNXI
EEPROM_SUNXI_SID
KEYBOARD_SUN4I_LRADC
SERIO_SUN4I_PS2
I2C_SUN6I_P2WI
SPI_SUN4I
IR_SUNXI
RTC_DRV_SUN6I
DMA_SUN6I
PWM_SUN4I
PHY_SUN9I_USB

I only own a beaglebone black, so not all drivers are of interest
there, but unless there's a reason not to: please enable.

Thanks,
Andre


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739009: gcc-arm-none-eabi: armv6 miscompilation

[Andre Heider]

Package: gcc-arm-none-eabi
Version: 4.8.2-14+6
Severity: normal
Tags: upstream patch

Hi,

I ran into this while cross compiling a kernel for the raspberry pi with this
toolchain.

I reported weird kernel crashes upstream [0] and found out this is a due to a
gcc v4.8 regression [1].
It's fixed upstream on the v4.8 branch [2], but as of this writing still
unreleased.

The official debian gcc-4.8 package comes with this fix (hidden in the huge
svn-updates.diff patch it comes with).
Additionally it has all the recent linaro patches on top (where this package
only has a couple for m0/m3).

There're tons of other fixes and improvements in those patches, and they're
already shipping as debian's native compilers on arm platforms.
For this issue the mentioned upstream fix would suffice, but why is this neat
bare metal cross compiler not build from that source package?

Thanks,
Andre

[0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
[1]
http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=d8e03d55d2e9801086aa8da2f9c347510aef8e11
[2] http://lists.infradead.org/pipermail/linux-rpi-
kernel/2014-February/000836.html
[3] http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.8/debian/patches
/svn-updates.diff?view=markuppathrev=7174



-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.2-mamamia+ (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-arm-none-eabi depends on:
ii  binutils-arm-none-eabi  2.24-2+4
ii  libc6   2.17-97
ii  libcloog-isl4   0.18.1-3
ii  libgmp102:5.1.3+dfsg-1
ii  libisl100.12.2-1
ii  libmpc3 1.0.1-1
ii  libmpfr43.1.2-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages gcc-arm-none-eabi recommends:
pn  libnewlib-arm-none-eabi  none

gcc-arm-none-eabi suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701807: GL_NV_vdpau_interop

[Andre Heider]

You can probably kill this one.

This patch introduces the usage of GL_NV_vdpau_interop in a way which
violates the specs:
https://bugs.freedesktop.org/show_bug.cgi?id=73191#c28 and #29.
It was fixed upstream just yesterday (comment #34).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737545: xbmc: unable to play dvds; not using system libdvdnav

[Andre Heider]

Package: xbmc
Version: 2:12.3+dfsg2-3
Severity: normal

xbmc offers play disc in the main menu when a dvd is present.
Choosing that options just ends in the log entry:

ERROR: Unable to load /usr/lib/xbmc/system/players/dvdplayer/libdvdnav-
x86_64-linux.so, reason: /usr/lib/xbmc/system/players/dvdplayer/libdvdnav-
x86_64-linux.so: cannot open shared object file: No such file or directory

system libdvdnav is present:

dpkg -L libdvdnav4:amd64|grep -w so
/usr/lib/x86_64-linux-gnu/libdvdnav.so.4.1.2
/usr/lib/x86_64-linux-gnu/libdvdnavmini.so.4.1.2
/usr/lib/x86_64-linux-gnu/libdvdnav.so.4
/usr/lib/x86_64-linux-gnu/libdvdnavmini.so.4

Apart from that the recent updates work great, thanks for taking care of the
package!



-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.1-mamamia (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xbmc depends on:
ii  fonts-dejavu-core  2.34-1
ii  fonts-roboto   1:4.3-2
ii  libjs-jquery   1.7.2+dfsg-3
ii  mesa-utils 8.1.0-2+b1
ii  python 2.7.5-5
ii  python-imaging 2.2.1-3.1
ii  python-support 1.0.15
ii  x11-utils  7.7+1
ii  xbmc-bin   2:12.3+dfsg2-3

xbmc recommends no packages.

xbmc suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org