Hello Rafael!
On 2023-11-15 06:47, Rafael Laboissière wrote:
> Does this mean that the origin of the bug is upstream or that it still may
> be a bug in gfortran?
At this point we know for sure that the issue is not armhf-specific, and
also that it is not caused by stack-clash-protection. On the
Hi!
On 2023-11-09 05:11, Rafael Laboissière wrote:
> The Fortran example x09f.f90, which is exercised during the building of
> plplot, now fails on armhf, due to the use of the compiler option
> -fstack-clash-protection.
The problem seems unrelated to stach-clash-protection I think, enabling
the
Hi Rafael,
On 2023-11-13 05:13, Rafael Laboissière wrote:
> The attached file bug-1055750.tgz contains a minimal code that
> triggers the bug on an armhf system
Thanks! For the record I can reproduce the issue in a armhf chroot, but
*not* on armel and arm64. The only thing to change in the
Package: gcc-13
Version: 13.2.0-6
Severity: normal
Dear Maintainer,
On arm64 dpkg-dev adds -mbranch-protection=standard to the default build
flags since version 1.22.0. However, the flag is not used in Debian and
Ubuntu when building GCC. This means that the feature does not work as
intended
Hi Roland!
On 2023-11-08 06:50, Roland Clobus wrote:
> I've run the commands that you have provided, and am unable to reproduce
> your case.
>
> lb config --distribution sid --updates false --archive-areas 'main
> non-free-firmware' --bootloaders grub-efi
> echo live-task-lxde >
On 2023-10-04 03:10, Emanuele Rocca wrote:
> P: Begin unmounting /sys...
> umount: /tmp/sid-image/chroot/sys: target is busy.
> E: An unexpected failure occurred, exiting...
The reason why /sys is busy is that efivarfs is mounted under
/sys/firmware/efi/efivars.
It seems that efiv
Hi Salvatore,
On 2023-11-04 09:57, Salvatore Bonaccorso wrote:
> I'm not sure this is really that urgent, 6.5.10 will be EOL upstream
> at some point and in master branch Bastian et all are prearing the 6.6
> based once. After an extra round in experimental I would expect it
> will now not take
Hi!
On 2023-10-05 10:05, John wrote:
> CONFIG_ARCH_R9A07G054=y
> CONFIG_ARCH_R9A07G043=y
> CONFIG_ARCH_R9A09G011=y
The changes have been merged into master some time ago already:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/867
Salvatore: what is the best way to ensure this makes
2023-10-09 11:45:48.0 +0200
@@ -1,3 +1,9 @@
+gcc-12 (12.2.0-14+deb12u1) bookworm; urgency=medium
+
+ * Fix -fstack-protector handling of overflows on AArch64 (CVE-2023-4039).
+
+ -- Emanuele Rocca Mon, 09 Oct 2023 11:45:48 +0200
+
gcc-12 (12.2.0-14) unstable; urgency=medium
Hi Dmitry!
On 2023-10-31 02:17, Dmitry Baryshkov wrote:
> BTW, Emanuele, are you by chance responsible for the X13s wiki page?
I started it, but most of the useful content has been provided by
someone else. :-)
See https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s?action=info
> There
Hi!
On Mon, Oct 30, 2023 at 07:54:25PM +0100, Vincent Blut wrote:
> Le 2023-10-30 20:30, Dmitry Baryshkov a écrit :
> > Package: src:linux
> > Version: 6.5.8-1
> > Severity: normal
> >
> > Please enable the following options as modules to enable audio support
> > on Lenovo X13s platform:
> >
>
Hi Guillem,
On 2023-10-27 04:33, Guillem Jover wrote:
> Checking now again, I realize Wookey mentioned enabling this for the 3
> arm arches (those would be arm64, armhf and armel), so the patch I
> provided would match that. But I was wondering now what about armeb and
> arm64ilp32? I mean, I
Package: dpkg-dev
Version: 1.22.0
Severity: normal
Tag: patch
Hi,
-fstack-clash-protection is supposed to be enabled by default on amd64,
arm64, armhf, and armel since dpkg 1.22.0:
https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=11efff1bf
However, due to an issue in the following conditional
Hi Uwe,
On 2023-10-24 06:48, Uwe Kleine-König wrote:
> I hesitate to actually enable it because I don't understand PCI good
> enough to judge it's a safe choice for the Debian kernel.
I am also not familiar with the details, but I see that PCI_P2PDMA is
'y' on both Fedora Server 38 and openSUSE
Source: shim
Version: 15.7-1
Severity: important
Tags: patch, upstream
Dear Maintainer,
shim 15.7-1 fails on some systems with the following error (visible with
SHIM_VERBOSE enabled):
mok.c:298:mirror_one_esl() 0040 e1 06 49 f2 69 9f 41 f4 31 13 88 20 XX
XX XX XX |..I.i.A.1.. |
Control: reassign -1 grub-efi-arm64-bin
Control: retitle -1 grub 2.12~rc1-10 fails loading linux on Renesas RZG2L, grub
2.06 works
Hi John, thanks for the bug report!
On 2023-10-11 04:15, John wrote:
> The ARM64 daily installer stopped working from 19-Sep-2023 due to grub2
> 2.12~rc1-10 updates
Hi Axel,
On 2023-10-10 01:45, Axel Beckert wrote:
> I tried that, installer ran through fine, grub boots from disk after
> installation, kernel loads initramfs and then falls into the initramfs
> prompt and fractions of a second later (sometimes even beforehand) the
> whole screen goes black and
Package: live-build
Version: 1:20230502
Severity: normal
Dear Maintainer,
Building a live image with `lb build` fails towards the end with the
following error:
P: Begin unmounting /sys...
umount: /tmp/sid-image/chroot/sys: target is busy.
E: An unexpected failure occurred, exiting...
The
Package: live-manual-pdf
Version: 2:20151217.2
Severity: important
Dear Maintainer,
All files under /usr/share/doc/live-manual/pdf/ seem to be broken.
Screenshot of `evince
/usr/share/doc/live-manual/pdf/live-manual.portrait.en.a4.pdf.gz`
attached.
I've also tried decompressing the file to
Hello Andrius,
On 2023-09-09 08:38, Andrius Merkys wrote:
> This is news to me. Could you please point out where in Debian Policy I can
> read more about such requirement? I thought I saw packages dropping support
> for one or another release architecture without being removed from testing.
See
Control: retitle -1 asmjit: FTBFS on armel and armhf
Hi Andrius,
On 2023-08-28 07:42, Andrius Merkys wrote:
> On Wed, 16 Aug 2023 14:29:10 +0200 Emanuele Rocca wrote:
> > asmjit does not build correctly on the following architectures:
> > armel, armhf, mips64el, mipsel, s
Hi Helmut,
On 2022-04-26 05:33, Helmut Grohne wrote:
> armnn fails to cross build from source for a fair number of reasons.
This does not seem to be the case anymore with 23.08-3 from
testing/unstable, at least judging from sbuild --host=arm64 on a x86
machine:
Package: wnpp
I'm not really using urlview much these days. If you want to be the new
maintainer, please take it.
See http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions on how to adopt a package properly.
Emanuele
Package: wnpp
Severity: normal
20 years after my first upload, 8 years since the last... it is high
time to orphan fortunes-it.
If you want to be the new maintainer, please take it -- see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions on how to adopt a package
Package: blhc
Version: 0.13-5
Severity: wishlist
Hi,
the flag -mbranch-protection=standard has been added to the default
build flags for arm64, and -fcf-protection for amd64, since dpkg 1.22.0.
It would be great if blhc could add support for both.
See
Package: blhc
Version: 0.13-5
Severity: wishlist
Hi,
the flag -fstack-clash-protection has been added to the default build
flags for amd64, arm64, armhf, and armel in dpkg 1.22.0.
It would be great if blhc could add support for it.
See https://bugs.debian.org/918914 and
Hi Guillem,
On 2023-08-31 02:12, Guillem Jover wrote:
> So this happened, and Johannes reported that this seems to be breaking
> cross-building. :(
>
> The problem, which is in fact not new, but is made way more evident
> now, is that the flags used are accepted only per arch, so when
> passing
Hallo Andreas,
On Fri, Aug 25, 2023 at 11:28:16AM +0200, Andreas Tille wrote:
> Am Wed, Aug 16, 2023 at 03:43:24PM +0200 schrieb Emanuele Rocca:
> > btllib currently fails to build from source on armhf with the following
> > tests-related error:
>
> Armhf (as well as
Hi,
On 2023-08-25 09:46, Graham Inggs wrote:
> On Fri, 25 Aug 2023 at 09:03, Andreas Tille wrote:
> > upstream does not support 32bit and the usage of this package on 32bit is
> > questionable anyway so please remove all 32bit builds of this package.
>
> Andreas, what 32-bit builds? bbhash has
Hi!
On 2023-08-22 04:42, Shengjing Zhu wrote:
> I can't reproduce it on abel.debian.org
> https://db.debian.org/machines.cgi?host=abel
> I assume you are cross building, or running it on an armhf/armel
> container on arm64 host.
Ah yes, good catch, I'm building on a arm64 host with:
sbuild
Source: cpu-features
Version: 0.7.0-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-...@lists.debian.org
Usertags: armhf armel
Hi,
cpu-features fails to build on armhf and armel with the following error:
In file included from /<>/test/cpuinfo_aarch64_test.cc:15:
Hi!
On 2023-08-21 07:36, Adam Borowski wrote:
> On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote:
> > Well FTBFS is a bug isn't it? :-)
>
> A FTBFS on an architecture that has built before (and hasn't been RMed)
> is a bug, and one that's policied as high seve
Control: retitle -1 cpp-httplib: FTBFS on s390x, armhf due to flaky tests
Hi,
On 2023-07-24 04:26, Andrea Pappacoda wrote:
> I've looked into this, but I couldn't find any change which would
> cause test failures on s390x specifically. cpp-httplib's test suite
> is a bit flaky though, so it may
Hi Adam,
On 2023-08-16 05:14, Adam Borowski wrote:
> This is not a regression, thus why would it be a bug?
Well FTBFS is a bug isn't it? :-)
> There's nothing in birdtray itself that would prevent it from being built on
> these architectures the moment problems in thunderbird are resolved
Why
Hi Matthias,
On 2023-08-18 06:46, Matthias Klose wrote:
> still ftbfs on arm64 and armhf. would it be possible to pay attention to
> build failures after uploads, or even better to pay attention until the
> package migrates?
See https://bugs.debian.org/1037579#43
We are currently packaging the
Source: coinor-bonmin
Version: 1.8.9-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
coinor-bonmin fails to build with the following error:
g++ -shared -nostdlib
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o .libs/BonCbc.o
Source: cctz
Version: 2.3+dfsg1-3
Severity: serious
Tags: sid trixie ftbfs
Hi,
cctz fails to build with the following error message:
75% tests passed, 1 tests failed out of 4
Total Test time (real) = 30.25 sec
The following tests FAILED:
2 - time_zone_lookup_test (Failed)
Errors
Source: coccinelle
Version: 1.1.1.deb-3
Severity: serious
Tags: sid ftbfs
User: debian-...@lists.debian.org
Usertags: armhf
Hi,
coccinelle fails to build from source on armhf with a "out of memory"
error.
(1) The error seems to be a red herring given that the machine on
which I'm building the
Source: btllib
Version: 1.4.10+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
Hi,
btllib currently fails to build from source on armhf with the following
tests-related error:
Iteration 1
Test FASTA
Source: birdtray
Version: 1.9.0+ds-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
Hi,
birdtray is 'Architecture: any' and build-depends on thunderbird.
However, armhf, armel, and mipsel are not in thunderbird's architecture
list. For this reason birdtray cannot be build on
Source: bbhash
Version: 1.0.0-5
Severity: serious
Tags: sid trixie ftbfs
Hi,
bbhash does not build correctly on the following 32 bit architectures:
armel, armhf, i386, mipsel.
g++ -o example_custom_hash example_custom_hash.cpp -O3 -std=c++11 -lpthread
In file included from example.cpp:1:
Source: asmjit
Version: 0.0~git20230427.3577608-1
Severity: serious
Tags: sid trixie ftbfs
Hi,
asmjit does not build correctly on the following architectures:
armel, armhf, mips64el, mipsel, s390x.
On armel, armhf, and s390x the error is tests-related:
[...]
1: Success:
1: All tests
Package: src:arm-compute-library
Version: 20.08+dfsg-7
Severity: serious
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-13
With GCC-13, arm-compute-library fails to build from source on both arm64 and
armhf with the following errors:
Hi!
On 2019-01-29 09:56, Guillem Jover wrote:
> Given its arch-dependent behavior this might need more exposure than a
> simple rebuild on say amd64. Enabling this at the beginning of a
> release cycle might seem more appropriate.
Lucas performed a full archive rebuild on arm64 with
Hi,
On 2023-08-14 01:16, John Vincent wrote:
> The RZ/G2L SMARC is the reference board for the Renesas RZ/G2L MPU:
> https://renesas.info/wiki/RZ-G/RZ-G2L_SMARC
>
> I think the following few configuration options in
> debian/config/arm64/config are missing to run Debian on this board.
>
> For
Note that since the upload of 20.08-13 the package now fails to build for
different reasons on i386 vs arm64/armhf.
I've opened https://bugs.debian.org/1042942 for i386.
On arm64/armhf the bug seems to be due to a missing include in
core/utils/misc/Utility.h from libarm-compute-dev.
[ 2%]
Package: src:armnn
Version: 20.08-13
Severity: serious
armnn 20.08-13 seems to compile correctly on i386, but then FTBFS due to
the following test failures:
Running 430 test cases...
./src/armnn/test/ModelAccuracyCheckerTest.cpp(103): [1;31;49merror: in
Hello Roman,
On 2023-07-01 04:18, Roman Mamedov wrote:
> There are 42 DTBs shipped with the installer for Allwinner alone:
> https://d-i.debian.org/daily-images/arm64/daily/device-tree/allwinner/
>
> But for the bootloader aka firmware aka u-boot:
>
Hi Matthias,
On 2023-07-12 08:22, Matthias Klose wrote:
> how will you care about build time regressions? The change is not
> difficult, however I'd like to see some commitment how to deal with these
> issues.
Happy to help should any issues arise.
FWIW there's no need to enable all arches in
Source: gcc-13-cross-ports
Version: 6
Severity: wishlist
Hi,
On amd64 hosts all ports are supported (ie: the binary package
gcc-13-alpha-linux-gnu and similar are available). That is not the case
for arm64 hosts. Please add arm64 to HOST_ARCHS_ in d/rules.
Thanks,
Emanuele
Hi,
On 2023-07-08 08:43, Matthias Klose wrote:
> [...]
> checking linker soname option... yes
> checking linker --demangle support... no
> checking linker plugin support... 0
> checking assembler for explicit relocation support... no
> checking assembler for -mno-shared support... no
> checking
Source: gcc-11-cross-mipsen
Version: 5+c3
Hi,
the following two binary packages seem to be missing:
- gcc-11-mips-linux-gnu
- gcc-11-mips-linux-gnu-base
We do however have the equivalent packages for GCC 10, 12, and 13 in
sid.
https://packages.debian.org/unstable/gcc-10-mips-linux-gnu
Hi Abou,
On 2023-07-06 01:59, Abou Al Montacir wrote:
> This was requested by upstream to investigate the issue.
I assume you've opened an upstream issue, but I can't find it on
https://gitlab.com/freepascal.org/fpc/source/-/issues/
Am I looking in the wrong place? Can you please point me at
Hello Abou,
On 2023-07-06 01:59, Abou Al Montacir wrote:
> Can you please give the output of fpc -i and fpc -vi?
> This was requested by upstream to investigate the issue.
Of course.
(sid-armhf)root@ariel:/var/tmp# fpc -vi hello.pas
Free Pascal Compiler version 3.2.2+dfsg-21 [2023/06/17] for
Package: wnpp
Severity: wishlist
Owner: Emanuele Rocca
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-r...@lists.debian.org
* Package name: parsec-tool
Version : 0.6.0
Upstream Author : Parsec Project Contributors
* URL : https://github.com/parallaxsecond/parsec
Package: debcargo
Version: 2.6.0-2
Severity: wishlist
Hi,
I'd like to have the option to use a custom Test-Command instead of
/usr/share/cargo/bin/cargo-auto-test for the generated autopkgtests.
The use case I have in mind is shipping a wrapper script under
debian/tests/ that does some initial
Package: fpc
Version: 3.2.2+dfsg-21
Hi,
binaries produced by fpc on armhf currently lack the hard-float ELF
flag.
I've built the following hello world program with `fpc hello.pas`:
program Hello;
begin
writeln ('Hello, world.');
end.
The resulting ELF object looks like this, note in
Hey Moritz,
On 2022-10-26 08:20, Moritz Mühlenhoff wrote:
> I think this should rather be applied early after the Bookworm
> release (and ideally we can also finish off the necessary testing
> and add -fstack-clash-protection at least for amd64 and other archs
> which are ready for it (#918914)).
Hi,
On 2023-06-18 06:30, Sam Uienn wrote:
> On Sat, 17 Jun 2023 10:46:37 +0200 Emanuele Rocca wrote:
> > After upgrading qbittorrent from 4.5.2 - currently in testing - to 4.5.3
> > in sid, all icons are gone.
>
> I've also noticed this problem on upgrade from 4.5.3-1 to 4
Hi Christian,
On 2023-06-17 11:26, Christian Marillat wrote:
> On 17 juin 2023 19:18, Emanuele Rocca wrote:
> > Yes. "Use custom UI Theme" is not set, "Use icons from system theme" is.
>
> I mixed up these two options in my previous e-mail.
>
>
Hi,
On 2023-06-17 04:57, Christian Marillat wrote:
> 'Use icons from system theme' is set in preferences ?
Yes. "Use custom UI Theme" is not set, "Use icons from system theme" is.
Please find a screenshot of qt5ct attached, it looks a little weird?
On 2023-06-17 02:49, Christian Marillat wrote:
> You must configure qt* for that.
>
> Install qt5ct
>
> sudo apt-get install qt5ct
>
> Add "export QT_QPA_PLATFORMTHEME=qt5ct" in the ~/.bashrc or ~/.zshrc
>
> In qt5ct go to 'Icon theme' tab and select an icon theme.
Done that, still no icons
Package: qbittorrent
Version: 4.5.3-2
Severity: important
Hi,
After upgrading qbittorrent from 4.5.2 - currently in testing - to 4.5.3
in sid, all icons are gone.
Please see the screenshots attached.
Emanuele
Hi Paul,
On 2023-04-25 10:03, Paul Gevers wrote:
> Your package has an autopkgtest, great. However, it fails since April 2023
> on arm64, i386, ppc64el and s390x. Can you please investigate the situation
> and fix it? I copied some of the output at the bottom of this report.
The reality of the
Package: tcc
Version: 0.9.27+git20200814.62c30a4a-1
Severity: wishlist
Hi,
executables compiled on armhf and armel target the ARM ABI Version4.
Since Debian 10 (Buster), the baseline was updated to Version 5: it
would be great if tcc could target Version 5 too.
ema@eniac:~
$ readelf -h
Hi again,
On 2023-05-31 05:46, Samuel Thibault wrote:
> The problem is that both are frown-prone. I guess there is a reason why
> on arm the default console is set to the serial port, e.g. for simpler
> debugging or something like that.
Also worth mentioning: there is no bug on real hardware
Hi,
On 2023-05-31 05:46, Samuel Thibault wrote:
> I'd rather see a patch like
>
> if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
> # Busybox's init uses a global TERM across all consoles.
> # If the serial console is the default such as on arm64, that
> # will force
Hi,
On Tue, May 30, 2023 at 09:08:45PM +0200, Cyril Brulebois wrote:
> Philip Hands (2023-05-30):
> > Apparently, this MR fixes the problem:
> >
> > https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8
> >
> > Although this does prompt the question of why aarch64 has TERM set
Hello,
following up here on the BTS for the benefit of those not reading #debian-boot.
On Wed, May 17, 2023 at 05:37:07PM +0200, Cyril Brulebois wrote:
> Emanuele Rocca (2023-05-17):
> > (B) failure to load the grub splash screen
[...]
> > sarzana dnsmasq-tftp[7413]: file /sr
Package: installation-reports
Boot method: PXE netboot
Image version: netboot.tar.gz from
https://deb.debian.org/debian/dists/testing/main/installer-amd64/20230515/images/netboot/
Machine: QEMU TCG x86_64 libvirt guest on aarch64 host
Base System Installation Checklist:
[O] = OK, [E] = Error
Control: tag -1 pending
Hi Adit,
On 2023-04-22 09:05, Adit Sahasrabudhe wrote:
> And I tested the patch at this link and it worked.
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=b3eff3e15576229af9bae026c5c23ee694b90389
Many thanks for finding the patch and trying it out. I can
Hi Vincent,
On 2023-03-20 01:36, Vincent Stehlé wrote:
> I think the Debian kernel is missing only a few configuration options in
> debian/config/arm64/config to run on that board.
Merge request opened:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/712
Emanuele
Hi Roland,
On 2023-05-03 04:54, Roland Clobus wrote:
> reassign 1035381 osinfo-db
> tags 1035381 +patch
> thanks
>
> Hello Emanuele, maintainers of osinfo-db,
>
> The version 20230308 in sid works fine for me for detecting the installer RC
> ISO images:
That is not the case for me. Which ISO
Hi Hector,
On Thu, May 04, 2023 at 05:53:24PM +0200, Hector Oron wrote:
> Since you have not uploaded the package yet, are you fine if I do a
> regular upload with the patch, then use this unblock request to add
> the package to bookworm.
Of course, please go ahead.
Thanks,
Emanuele
/changelog 2023-05-04 13:40:28.0 +0200
@@ -1,3 +1,11 @@
+gdb (13.1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * aarch64: add aarch64-pauth-registers.patch to check for valid inferior
+thread/regcache before reading pauth registers. (Closes: #1034611)
+
+ -- Emanuele
Hi again,
On 2023-05-03 08:16, Axel Beckert wrote:
> Machine: Thinkpad X13s (ARM)
Sorry, I've realized only after sending my previous message and having a
coffee that this is about the X13s. :)
The X13s is unfortunately not supported by Linux 6.1 that Bookworm will
ship with. Hopefully 6.4 will
Hi Axel,
On 2023-05-03 08:16, Axel Beckert wrote:
> After choosing either "expert install" (first and prefered try) or
> "graphical expert install" (second try and second choice) I saw these
> three lines and then nothing more happened:
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Using
Package: virt-manager
Version: 1:4.1.0-2
X-Debbugs-CC: debian-b...@lists.debian.org
Hi,
Step 2 of the "Create a new virtual machine" wizard fails to
automatically detect the operating system when using an RC version of
d-i such as [0]. See attached screenshot.
Stable images like [1] are
Hi Adam,
On Thu, Apr 27, 2023 at 05:52:42PM +0200, Adam Borowski wrote:
> Ie, /sbin/fsck.btrfs serves no purpose that'd be useful in an udeb.
>
> Before I close this report, may I ask if you have a purpose for this
> stub? You probably wanted a full-blown recovery tool, but I may be
> getting
Hi,
On Tue, Jul 12, 2016 at 08:22:31PM +0200, Ansgar Hegerfeld wrote:
> Okay, thanks. I opened a bugreport upstream:
> https://bugzilla.redhat.com/show_bug.cgi?id=1355857
The upstream bug was fixed a long time ago. Is the issue still reproducible in
Debian, or can this bug be closed?
Thanks,
Package: btrfs-progs
Version: 6.2-1
X-Debbugs-CC: debian-b...@lists.debian.org
Tags: patch
Hi,
the btrfs-progs udeb currently includes only /bin/btrfs and /bin/mkfs.btrfs.
Please add /sbin/fsck.btrfs as well so that it can be included in the initramfs
generated by the debian installer. Patch
Hi Vincent,
On Sat, Apr 22, 2023 at 02:58:22AM +0200, Vincent Danjean wrote:
> I made a push request[1] but I missed the fact that it fails.
> It was due to the tests being run with sh(dash) instead of bash or
> busybox sh.
> So, I just fixed the code so that it works with any of these 3
Control: tags -1 + patch
Proposed fix:
https://salsa.debian.org/grub-team/grub/-/merge_requests/32
On 2023-03-29 04:13, Emanuele Rocca wrote:
> We need to be able to reproduce the issue (a) with a self-signed
> version of grub.
I did manage to reproduce with a self-signed grub by using a new key
instead of the one included in AAVMF_VARS.snakeoil.fd. The latter is
included in PK and DB,
On 2023-03-29 06:55, Helmut Grohne wrote:
> At this point, my preference is max,pauth-impdef=on.
Agreed.
> Would someone confirm that this also speeds up on arm64?
Confirmed.
Thanks!
ema
Hi,
On 2023-03-29 01:12, Arnd Bergmann wrote:
> a) try to reproduce the behavior on an x86-64 host
Good point. Also on a x86-64 host cpu=cortex-a57 is significantly
faster:
max:
[ 30.086331] systemd[1]: Hostname set to .
cortex-a57:
[ 13.870771] systemd[1]: Hostname set to .
Package: grub-efi-arm64-signed
Version: 2.06-8
Hi,
Secure Boot does not work on arm64 using the shim signed by Microsoft [0] and
grub2 signed by Debian [1] currently in sid.
(a) SB not working with Debian's shim, grub and kernel:
$ sbverify --list /mnt/efi/boot/bootaa64.efi | grep subject
Package: debvm
Version: 0.2.9
Hi,
some arm64 hosts unfortunately do not have KVM support:
kvm [1]: HYP mode not available
On those systems, running qemu with -cpu=cortex-a57 results in
significantly improved performance compared to -cpu=max.
For example: here is how long it takes debvm-run
Hi,
On Mon, Mar 27, 2023 at 06:23:57PM +0200, Michael Biebl wrote:
> Please consider raising this issue upstream
There's no need, the bug is fixed in main (currently at 3a051522).
It is however reproducible checking out tag v253, so presumably upstream
version v254 will be the first release
Source: edk2
Version: 2022.11-6
Severity: wishlist
Hi,
edk2 binaries are currently built with BUILD_TYPE = RELEASE [1].
For debugging purposes, it is also possible to build them with
BUILD_TYPE = DEBUG. It would be great if debug versions of OVMF_CODE and
AAVMF_CODE could be built, perhaps
Package: systemd-boot-efi
Version: 252.6-1
Hi,
booting in Secure Boot mode with a self-signed systemd-bootaa64.efi
works well on arm64. However, trying to boot via shimaa64.efi fails with
the following error:
shim.c:866:load_image() attempting to load \EFI\BOOT\grubaa64.efi
Package: systemd
Version: 252.6-1
Hi,
the systemd binary package currently ships the following files:
/usr/bin/kernel-install
/usr/share/bash-completion/completions/kernel-install
/usr/share/man/man8/kernel-install.8.gz
/usr/share/zsh/vendor-completions/_kernel-install
Given that AFAIU
Hi Vincent,
On 2023-03-24 11:03, Vincent Danjean wrote:
> However, I did not rebuild all the installer packages to generate a
> new installer and test it in real conditions.
I haven't had the time to test your patch yet, but there's a hack I'd
like to share to test things in d-i without
Hi Vincent,
On 2021-06-20 10:54, Vincent Danjean wrote:
> Would someone give a feedback to the (old) patch proposed
> in #913431 in order to be able to also use power-of-two units
> in the Debian Installer?
It took a while, sorry about that. :)
There is (now) a function in partman-base called
+
+ * Actually include d/patches/missing-includes.patch, all changes to d/patches
+got removed by dgit.
+
+ -- Emanuele Rocca Fri, 03 Mar 2023 14:31:21 +0100
+
+arm-compute-library (20.08+dfsg-6) unstable; urgency=medium
+
+ * Add d/patches/missing-includes.patch to fix FTBFS (Closes: #1032041)
+ * Add
Hi Jeremy and Simon!
On 2023-03-15 11:50, Emanuele Rocca wrote:
> Motivated by this, I've tried to build mozjs78 with GCC 11 instead of
> 12, and it *did* build successfully. My proposal is thus to build
> mozjs78 with GCC 11 on armhf and armel, see attached patch.
I've now d
* Non-maintainer upload.
+ * Build with GCC 11 on armhf and armel (Closes: #1029167).
+
+ -- Emanuele Rocca Wed, 15 Mar 2023 10:36:30 +0100
+
mozjs78 (78.15.0-6) unstable; urgency=medium
* Add patch to fix build with Python 3.11 (Closes: #1028308)
diff -Nru mozjs78-78.15.0/debian/control.
On 2023-01-27 12:03, Adrian Bunk wrote:
> WITH_SYSTEM_ICU = yes fixes this error on armel.
And on armhf too.
> The build fails later due to 146 TEST-UNEXPECTED-FAIL,
> which is not a problem for 0ad who aren't running the mozjs testsuite.
Of those 146 test failures, many seem to be
Package: depthcharge-tools-installer
Hi,
while looking at d-i logs for one of my systems I've noticed the following
message repeated many times:
depthcharge-tools-installer: Not installing to non-ChromeOS board.
Please consider removing the logging statement from isinstallable.
Thanks,
ema
Hi Christian,
On Fri, Mar 10, 2023 at 08:24:22AM +0100, Christian Ehrhardt wrote:
> So I wondered if/how we should consider replacing dstat with dool in Debian?
Thanks for starting the discussion. I agree that dstat in Debian could use some
improvement! :-)
Dool looks good, let's get it in the
101 - 200 of 412 matches
Mail list logo
