PPC (32-bit) Kernel Version

[Dan Whitehouse]

Hi all,
I have a powermac-g4 with debian installed.
Some time ago I experienced an issue with the kernel which caused a hard lock.
I have been working around this using apt pinning.
My current kernel is:

Linux powermac-g4 6.8.12-powerpc #1 Debian 6.8.12-1 (2024-05-31) ppc GNU/Linux


And in apt/preferences.d/00-kernel I have:

package: linux-image-6.9.7-powerpc
Pin: version 6.9.7-1
Pin-Priority: -1

package: linux-image-6.9.12-powerpc
Pin: version 6.9.12-1
Pin-Priority: -1

I’m not even sure how correct that is, but it seems to have let me run apt 
update / upgrade without updating the kernel to the one that caused the hard 
lock.

So, I guess my question is, am I now safe to remove that pinning, or are there 
still issues?

I know I could just test, but this machine is headless and heavy so I’m being 
lazy!

Thanks,

Dan

Bug#1100389: sysdig: FTBFS on riscv64: ‘luaL_setfuncs’ was not declared in this scope;

[Bo YU]

Source: sysdig
Version: sysdig: 0.40.0+repack-1
Severity: serious
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org, debian-powerpc@lists.debian.org

Dear Maintainer,

sysdig has one FTBFS issue on risv64:

```
/build/reproducible-path/sysdig-0.40.0+repack/userspace/chisel/chisel.cpp:985:9:
 error: ‘luaL_setfuncs’ was not declared in this scope; did you mean 
‘lua_setfenv’?
  985 | luaL_setfuncs(ls, ll_tool, 0);
  | ^
  | lua_setfenv
/build/reproducible-path/sysdig-0.40.0+repack/userspace/chisel/chisel.cpp: In 
member function ‘void sinsp_chisel::load(std::string, bool)’:
/build/reproducible-path/sysdig-0.40.0+repack/userspace/chisel/chisel.cpp:1196:9:
 error: ‘luaL_setfuncs’ was not declared in this scope; did you mean 
‘lua_setfenv’?
 1196 | luaL_setfuncs(m_ls, ll_tool, 0);
  | ^
  | lua_setfenv
...
```

Please to see the full buildd log:
https://buildd.debian.org/status/fetch.php?pkg=sysdig&arch=riscv64&ver=0.40.0%2Brepack-1&stamp=1741839403&raw=0

It seems the build-dependence on riscv64 will need switch to
libluajit-5.1-dev[0] also and it works on my local build.

BTW, sysdig has FTBFS issues on armel, mips64el, ppc64el and
s390x[1], I guess once libfalcosecurity0-dev catch up on armel and s390x
the building will be okay. In fact, I did a giveback on mips64el and it
worked. But for ppc64el, unfortunately, these is no libluajit-5.1
supported, so unless other workaround, otherwise it has FTBFS on ppc64el
always. So I am ccing the ppc porter to have a look at this.

[0]: https://tracker.debian.org/pkg/luajit
[1]: https://buildd.debian.org/status/package.php?p=sysdig

-- 
Regards,
--
  Bo YU

diff -Nru sysdig-0.40.0+repack/debian/changelog 
sysdig-0.40.0+repack/debian/changelog
--- sysdig-0.40.0+repack/debian/changelog   2025-02-22 00:51:54.0 
+
+++ sysdig-0.40.0+repack/debian/changelog   2025-03-13 08:01:04.0 
+
@@ -1,3 +1,11 @@
+sysdig (0.40.0+repack-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build dependence with libluajit-5.1-dev explicitly on riscv64.
+(Closes: #-1)
+
+ -- Bo YU   Thu, 13 Mar 2025 08:01:04 +
+
 sysdig (0.40.0+repack-1) unstable; urgency=medium
 
   * New upstream release (Closes: #1095317)
diff -Nru sysdig-0.40.0+repack/debian/control 
sysdig-0.40.0+repack/debian/control
--- sysdig-0.40.0+repack/debian/control 2024-10-17 13:04:37.0 +
+++ sysdig-0.40.0+repack/debian/control 2025-03-13 08:01:04.0 +
@@ -20,7 +20,7 @@
zlib1g-dev,
uthash-dev,
 # Same as the dependency in falcosecurity-libs
-   libluajit-5.1-dev [amd64 arm64 armel armhf i386 mips64el s390x] 
| liblua5.1-0-dev
+   libluajit-5.1-dev [amd64 arm64 armel armhf i386 mips64el 
riscv64 s390x] | liblua5.1-0-dev
 Standards-Version: 4.5.0
 Homepage: https://www.sysdig.com/
 Vcs-Git: https://salsa.debian.org/debian/sysdig.git


signature.asc
Description: PGP signature