Re: Ability to further support 32bit architectures

[John Paul Adrian Glaubitz]

Hi!

On Thu, 2024-01-11 at 10:25 +0100, Bastian Blank wrote:
> Linux 6.7 fails to build on at least i386 and armhf.  Even it now
> manages to make the compiler fail to allocate memory:
> > cc1: out of memory allocating 135266296 bytes after a total of 235675648 
> > bytes
> 
> Right now both fail on the same driver, so a short team workaround would
> be to disable it.  But we need a long term fix, and quickly.

The long term fix would be fixing this driver so a single compilation unit 
doesn't
take several gigabytes of RAM.

> As it is now, we will not be able to provide a kernel for maybe all
> 32bit architectures for Trixie.

I don't think that this would be a reasonable decision. We're preparing to 
switch
32-bit architectures over to time64_t. Disabling 32-bit kernel builds would make
this whole work moot.

FWIW, both m68k and powerpc are not affected by this bug, the powerpc build 
fails
because of a packaging problem.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Ability to further support 32bit architectures

[Bastian Blank]

On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote:
> > As it is now, we will not be able to provide a kernel for maybe all
> > 32bit architectures for Trixie.
> I don't think that this would be a reasonable decision. We're preparing to 
> switch
> 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would 
> make
> this whole work moot.

This is completely unrelated.  Userland != kernel.  And people already
talked about only supporting userland for those architectures.

> FWIW, both m68k and powerpc are not affected by this bug, the powerpc build 
> fails
> because of a packaging problem.

Actually powerpc fails for exactly the same reason:

| cc1: out of memory allocating 135266296 bytes after a total of 244908032 bytes
| make[9]: *** [/<>/scripts/Makefile.build:248: 
drivers/media/pci/solo6x10/solo6x10-p2m.o] Error 1

https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.7-1%7Eexp1=1704796355=0

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Re: Ability to further support 32bit architectures

[Adrian Bunk]

On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
> 
> Okay, maybe more workarounds exist.  But none of them look really
> promising.
>...

gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.

But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.

> Bastian

cu
Adrian

Processed: bookworm-pu: package apktool/2.7.0+dfsg-6+deb12u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:apktool
Bug #1060433 [release.debian.org] bookworm-pu: package 
apktool/2.7.0+dfsg-6+deb12u1
Added indication that 1060433 affects src:apktool

-- 
1060433: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060433
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1060433: bookworm-pu: package apktool/2.7.0+dfsg-6+deb12u1

[Hans-Christoph Steiner]

Package: release.debian.org
Control: affects -1 + src:apktool
X-Debbugs-Cc: apkt...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal

[ Reason ]

This fixes CVE-2024-21633.

[ Impact ]

If this is not included, bookworm users will be vulnerable to attacks
when analyzing malicious APKs with apktool.  These attacks will be
able to write/overwrite any file that the user has permission to.

[ Tests ]

The existing autopkgtest covers code/functionality that is patched.

[ Risks ]

It is a very simple fix and problems should be rapidly visible via the
tests.  Worst case, apktool will decompile a file to the wrong
location, but will tell the user the path.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Include upstream patch to 2.7.0 to fix CVE-2024-21633.

[ Other info ]

Upstream reached out to help get this updated in Debian, so they
deemed it quite important to fix.  This is the first time upstream has
communicated with the Debian maintainers about this package, IIRC.
diff -Nru apktool-2.7.0+dfsg/debian/changelog 
apktool-2.7.0+dfsg/debian/changelog
--- apktool-2.7.0+dfsg/debian/changelog 2023-03-21 09:41:45.0 +0100
+++ apktool-2.7.0+dfsg/debian/changelog 2024-01-10 20:08:30.0 +0100
@@ -1,3 +1,11 @@
+apktool (2.7.0+dfsg-6+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * CVE-2024-21633: Prevent arbitrary file writes with malicious resource
+names. (Closes: #1060013)
+
+ -- Hans-Christoph Steiner   Wed, 10 Jan 2024 20:08:30 +0100
+
 apktool (2.7.0+dfsg-6) unstable; urgency=medium
 
   * only test APK build on arches with aapt that can do it
diff -Nru 
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
 
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
--- 
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
 1970-01-01 01:00:00.0 +0100
+++ 
apktool-2.7.0+dfsg/debian/patches/CVE-2024-21633-Prevent-arbitrary-file-writes-with-malicious-resourc.patch
 2024-01-10 20:07:42.0 +0100
@@ -0,0 +1,92 @@
+From 087f89ebc0dd87e74c8945f074f25b51b195cb83 Mon Sep 17 00:00:00 2001
+From: Connor Tumbleson 
+Date: Tue, 2 Jan 2024 06:11:03 -0500
+Forwarded: 
https://github.com/iBotPeaches/Apktool/commit/087f89ebc0dd87e74c8945f074f25b51b195cb83
+Subject: [PATCH 1/1] Prevent arbitrary file writes with malicious resource
+ names. (#3484)
+
+CVE-2024-21633
+
+* refactor: rename sanitize function
+
+* fix: expose getDir
+
+* fix: safe handling of untrusted resource names
+
+ - fixes: GHSA-2hqv-2xv4-5h5w
+
+* test: sample file for GHSA-2hqv-2xv4-5h5w
+
+* refactor: avoid detection of absolute files for resource check
+
+* chore: enable info mode on gradle
+
+* test: skip test on windows
+
+* chore: debug windows handling
+
+* fix: normalize entry with file separators
+
+* fix: normalize filepath after cleansing
+
+* chore: Android paths are not OS specific
+
+* refactor: use java.nio for path traversal checking
+
+* chore: align path separator on Windows for Zip files
+
+* chore: rework towards basic directory traversal
+
+* chore: remove '--info' on build.yml
+---
+ .../java/brut/androlib/res/decoder/ResFileDecoder.java| 8 
+ brut.j.util/src/main/java/brut/util/BrutIO.java   | 7 +++
+ 2 files changed, 15 insertions(+)
+
+diff --git 
a/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
 
b/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
+index a3174411..16ad35f9 100644
+--- 
a/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
 
b/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java
+@@ -25,6 +25,7 @@ import brut.androlib.res.data.value.ResFileValue;
+ import brut.directory.DirUtil;
+ import brut.directory.Directory;
+ import brut.directory.DirectoryException;
++import brut.util.BrutIO;
+ 
+ import java.io.*;
+ import java.util.Map;
+@@ -47,6 +48,13 @@ public class ResFileDecoder {
+ String outResName = res.getFilePath();
+ String typeName = res.getResSpec().getType().getName();
+ 
++if (BrutIO.detectPossibleDirectoryTraversal(outResName)) {
++outResName = inFileName;
++LOGGER.warning(String.format(
++"Potentially malicious file path: %s, using instead %s", 
res.getFilePath(), outResName
++));
++}
++
+ String ext = null;
+ String outFileName;
+ int extPos = inFileName.lastIndexOf(".");
+diff --git a/brut.j.util/src/main/java/brut/util/BrutIO.java 
b/brut.j.util/src/main/java/brut/util/BrutIO.java
+index 

Re: Ability to further support 32bit architectures

[Dimitri John Ledkov]

Hi,

On Thu, 11 Jan 2024 at 09:42, Bastian Blank  wrote:
>
> Hi
>
> Linux 6.7 fails to build on at least i386 and armhf.  Even it now
> manages to make the compiler fail to allocate memory:
> | cc1: out of memory allocating 135266296 bytes after a total of 235675648 
> bytes
>
> Right now both fail on the same driver, so a short team workaround would
> be to disable it.  But we need a long term fix, and quickly.
>
> As it is now, we will not be able to provide a kernel for maybe all
> 32bit architectures for Trixie.
>
> Bastian
>

Disabling debug symbols, enabling debug symbol zstd compression, using
split debug symbols (disabled BTF usage) should help here.

Separately, I wish we had cross-builders available, and cross-build
i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
compiler.

I am experiencing the same issue with the armhf kernels on my infrastructure.

-- 
Dimitri

Sent from Ubuntu Pro
https://ubuntu.com/pro

Re: Ability to further support 32bit architectures

[Bastian Blank]

Hi

On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.

Okay, maybe more workarounds exist.  But none of them look really
promising.

> Separately, I wish we had cross-builders available, and cross-build
> i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> compiler.

Real cross-builders would use some fast amd64/arm64/ppc64el (and for
amd64 also reasonably cheap) machines to build all other architectures.

Bastian

-- 
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7

Ability to further support 32bit architectures

[Bastian Blank]

Hi

Linux 6.7 fails to build on at least i386 and armhf.  Even it now
manages to make the compiler fail to allocate memory:
| cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes

Right now both fail on the same driver, so a short team workaround would
be to disable it.  But we need a long term fix, and quickly.

As it is now, we will not be able to provide a kernel for maybe all
32bit architectures for Trixie.

Bastian

-- 
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown

Re: Ability to further support 32bit architectures

[John Paul Adrian Glaubitz]

Hello Dimitri,

On Thu, 2024-01-11 at 09:48 +, Dimitri John Ledkov wrote:
> Separately, I wish we had cross-builders available, and cross-build
> i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> compiler.

Helmut Grohne is actually working towards cross-builders and I think there
is a chance we might see these in the foreseeable future.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1059929: marked as done (release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency)

[Debian Bug Tracking System]

Your message dated Thu, 11 Jan 2024 12:32:33 +0100
with message-id <49eda68c-9a49-41f0-9975-b95fa491f...@debian.org>
and subject line Re: Bug#1059929: release.debian.org: 
gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
has caused the Debian Bug report #1059929,
regarding release.debian.org: gobject-introspection_1.78.1-9 is said to have an 
unsatisfiable dependency
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1059929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059929
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney
X-Debbugs-Cc: gobject-introspect...@packages.debian.org, 
debian-cr...@lists.debian.org

gobject-introspection in experimental has this in
https://release.debian.org/britney/pseudo-excuses-experimental.html#gobject-introspection:

gobject-introspection (1.78.1-6 to 1.78.1-9)

Migration status for gobject-introspection (1.78.1-6 to 1.78.1-9): BLOCKED: 
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
gobject-introspection/amd64 has unsatisfiable dependency
gobject-introspection/arm64 has unsatisfiable dependency
Additional info:
uninstallable on arch amd64, not running autopkgtest there
uninstallable on arch arm64, not running autopkgtest there

The gobject-introspection binary package *is* installable, and in fact
I have it installed locally. Taking the amd64 version as an example,
it depends on:

- binutils-x86-64-linux-gnu:any, a real Multi-Arch: allowed package

- gcc-x86-64-linux-gnu, a virtual package provided by gcc:amd64

- gobject-introspection-bin | qemu-user | qemu-user-static, where
  g-i-bin is a Multi-Arch: allowed package from the same source

- gobject-introspection-little-endian:any, a virtual package provided
  by g-i-bin, which is Multi-Arch: allowed
  (experimentally, apt and dpkg both seem to be happy to assume that
  this makes the gobject-introspection-little-endian virtual package
  behave as though it was also Multi-Arch: allowed)

- pkgconf, a real package

- python3:any, a real Multi-Arch: allowed package

I think all of those are correct?

Or do I need to make gobject-introspection-bin Multi-Arch: foreign,
drop the :any from gobject-introspection-little-endian:any, and
replace the gobject-introspection-bin | qemu-user | qemu-user-static
dependency by python3 | qemu-user | qemu-user-static or similar?

My goal here is that you can install gobject-introspection:amd64 on an
amd64 machine, or on any other little-endian machine that will be able to
cross-compile amd64 binaries and then run them by explicitly invoking them
via qemu-user, as discussed with Helmut Grohne at the recent Cambridge
miniDebconf. (It has to be little-endian because g-ir-inspect and similar
tools don't currently support byte-swapping fields in binary typelibs.)

Thanks,
smcv
--- End Message ---
--- Begin Message ---

Hi Simon,,

On 05-01-2024 21:57, Paul Gevers wrote:

Control: tags -1 pending

Hi,

On 03-01-2024 20:40, Paul Gevers wrote:

On 03-01-2024 20:22, Simon McVittie wrote:

I think all of those are correct?


I think that if apt allows you to install it, chances are that it's a 
britney2 bug. I'll try to debug it tomorrow.


I have a first proposal for a fix in 
https://salsa.debian.org/release-team/britney2/-/merge_requests/89


This is pushed, so these two issues should be solved now.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#971739: marked as done (release.debian.org: britney thinks ghostscript B-D on libz-dev:native is unsatisfiable)

[Debian Bug Tracking System]

Your message dated Thu, 11 Jan 2024 12:32:33 +0100
with message-id <49eda68c-9a49-41f0-9975-b95fa491f...@debian.org>
and subject line Re: Bug#1059929: release.debian.org: 
gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
has caused the Debian Bug report #971739,
regarding release.debian.org: britney thinks ghostscript B-D on libz-dev:native 
is unsatisfiable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971739
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney

The excuses on  say:
* ghostscript unsatisfiable Build-Depends(-Arch) on amd64: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on arm64: libz-dev:native
(etc.)

(ghostscript's migration is also blocked by FTBFS #971678, but that isn't
the significant thing here.)

However, sbuild successfully satisfies the dependency: libz-dev is a
virtual package provided by zlib1g-dev (only), and sbuild seems to
interpret it as equivalent to zlib1g-dev:native, which is satisfiable.
britney should probably do the same.

I've also opened a ghostscript bug recommending that the B-D should be
swapped to the more canonical form zlib1g-dev:native to work around this.

smcv
--- End Message ---
--- Begin Message ---

Hi Simon,,

On 05-01-2024 21:57, Paul Gevers wrote:

Control: tags -1 pending

Hi,

On 03-01-2024 20:40, Paul Gevers wrote:

On 03-01-2024 20:22, Simon McVittie wrote:

I think all of those are correct?


I think that if apt allows you to install it, chances are that it's a 
britney2 bug. I'll try to debug it tomorrow.


I have a first proposal for a fix in 
https://salsa.debian.org/release-team/britney2/-/merge_requests/89


This is pushed, so these two issues should be solved now.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---

Re: Ability to further support 32bit architectures

[Aurelien Jarno]

On 2024-01-11 13:24, Adrian Bunk wrote:
> On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
> >...
> > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > 
> > Okay, maybe more workarounds exist.  But none of them look really
> > promising.
> >...
> 
> gcc being a memory hog on for C++ code is a hard problem,
> and debug symbols for C++ code can be a problem since
> they might be > 1 GB for some binaries.
> 
> But gcc needing more than 4 GB for a small C kernel driver is not
> a problem for the "Ability to further support 32bit architectures",
> that's a gcc bug that should be reported upstream just like you wouldn't
> suggest dropping amd64 if gcc would ICE on one kernel driver on that
> architecture.

Or maybe just blame the kernel instead:
https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w...@mail.gmail.com/

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Processed: block 1055955 with 1060458

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 1055955 with 1060458
Bug #1055955 [release.debian.org] transition: perl 5.38
1055955 was blocked by: 1042844 1054776 1050451 1057318 1060323 1042845 1057270 
1040396 1042853 1057424 1042525 1042521 1054793
1055955 was not blocking any bugs.
Added blocking bug(s) of 1055955: 1060458
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1055955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#1026046: FTBFS: test failures on some architectures

[Debian Bug Tracking System]

Processing control commands:

> found -1 0.51-1
Bug #1026046 [src:libdevel-mat-perl] libdevel-mat-perl: FTBFS: test failures on 
some architectures
Marked as found in versions libdevel-mat-perl/0.51-1.
> severity -1 serious
Bug #1026046 [src:libdevel-mat-perl] libdevel-mat-perl: FTBFS: test failures on 
some architectures
Severity set to 'serious' from 'important'
> block 1055955 with -1
Bug #1055955 [release.debian.org] transition: perl 5.38
1055955 was blocked by: 1060458 1042525 1060323 1054776 1057270 1040396 1050451 
1042845 1042521 1057424 1042853 1057318 1054793 1042844
1055955 was not blocking any bugs.
Added blocking bug(s) of 1055955: 1026046

-- 
1026046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026046
1055955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: block 1055955 with 1060653

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 1055955 with 1060653
Bug #1055955 [release.debian.org] transition: perl 5.38
1055955 was blocked by: 1057270 1050451 1042844 1042521 1060458 1042525 1054793 
1042845 1057424 1026046 1060456 1042853 1040396 1057318 1060323 1054776
1055955 was not blocking any bugs.
Added blocking bug(s) of 1055955: 1060653
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1055955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: unblock 1055955 with 1042845 1040396

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # only in sid
> unblock 1055955 with 1042845 1040396
Bug #1055955 [release.debian.org] transition: perl 5.38
1055955 was blocked by: 1060653 1042844 1060323 1042845 1057318 1060456 1026046 
1057424 1042853 1040396 1060458 1042521 1054793 1042525 1054776 1057270 1050451
1055955 was not blocking any bugs.
Removed blocking bug(s) of 1055955: 1042845 and 1040396
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1055955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: block 1055955 with 1060456, user debian-p...@lists.debian.org, usertagging 1060456

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 1055955 with 1060456
Bug #1055955 [release.debian.org] transition: perl 5.38
1055955 was blocked by: 1054776 1042521 1042525 1060458 1057318 1060323 1050451 
1054793 1042844 1042845 1057424 1057270 1026046 1040396 1042853
1055955 was not blocking any bugs.
Added blocking bug(s) of 1055955: 1060456
> user debian-p...@lists.debian.org
Setting user to debian-p...@lists.debian.org (was nt...@debian.org).
> usertags 1060456 perl-5.38-transition
There were no usertags set.
Usertags are now: perl-5.38-transition.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1055955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055955
1060456: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060456
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

[Simon McVittie]

On Thu, 04 Jan 2024 at 09:54:52 +0100, Helmut Grohne wrote:
> I am not sure that you are the one who should express a qemu dependency.

Discussion of whether gobject-introspection has the ideal dependencies
seems off-topic for a release.d.o bug, so I've sent a reply to #1030223,
dropping the release and apt teams from cc (but keeping -cross). Please
follow up there with any further g-i-specifics.

The part of this issue that was relevant for release.d.o was: given
the current metadata of g-i_1.78.1-9, was britney2 correct to think its
deps are satisfiable? And the answer was: no, it was a bug that britney2
disagreed with apt on this.

According to the experimental pseudo-excuses, it seems that Paul's fix
for that bug was successful, and the fixed version of britney2 is now
happy to (pretend to) migrate g-i_1.78.1-9 if its autopkgtests pass.

Thanks,
smcv

Re: Ability to further support 32bit architectures

[Jeffrey Walton]

On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank  wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist.  But none of them look really
> promising.

Also see .

> > Separately, I wish we had cross-builders available, and cross-build
> > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> > compiler.
>
> Real cross-builders would use some fast amd64/arm64/ppc64el (and for
> amd64 also reasonably cheap) machines to build all other architectures.

Jeff