Bug#922729: debootstrap: unable to override arch-test

Package: debootstrap Followup-For: Bug #922729 Hello The workaround I found was to install the binfmt-support and qemu-user-static packages, when debootstrap'ing an arm64 chroot on a amd64 host. Thank you -- Sylvain

Bug#974991: sagemath: segfault on startup

Hello >From trial and error, my workaround is to downgrade python3-cypari2. I have no idea whether it is appropriate or if it is going to trigger something else, but at least I don't have a startup crash anymore. Here are the steps: - add "deb

Bug#950324: /boot/vmlinuz-5.4.0-3-marvell: 5.4.0-3-marvell vmlinuz too large for QNAP TS119 mtd, "Not enough space for kernel" error

Package: src:linux Version: 5.4.13-1 Severity: important File: /boot/vmlinuz-5.4.0-3-marvell Dear Maintainer, I tried updating from linux-image-4.19.0-5-marvell to linux-image-5.4.0-3-marvell. During installation, the update fails with the following message: update-initramfs: Generating

Bug#818652: dovecot-imapd: Crash upon virtual folder selection after update to 1:2.2.21-1 (follow-up)

> This line tell me it is a null pointer to a struct with at least 0x20 > members being used in mail_search_args_equal(): Thank you for this. The crash is reproducible by issuing a UID search similar to the virtual folder definition. In imapfilter terms, it means that if I issue mails =

Bug#818652: dovecot-imapd: Crash upon virtual folder selection after update to 1:2.2.21-1 (follow-up)

> So just to confirm, this virtual folder was working in < 2.2.21 but stopped > working afterwards? Yes, selection of this folder with this dovecot-virtual content was working with 1:2.2.18-2+b1 but now segfaults dovecot-imapd 1:2.2.21-1. I just tested with 1:2.2.22-1 from unstable, I still have

Bug#818652: dovecot-imapd: Crash upon virtual folder selection after update to 1:2.2.21-1 (follow-up)

Hi again I dug deeper, and I can now reproduce the crash on x86_64 as well. It boils down to the content of dovecot-virtual. ~/.Mail/virtual$ cat test/dovecot-virtual Tous les messages OR (INTHREAD REFS YOUNGER 100) (YOUNGER 100) If I select the test folder, dovecot-imapd crashes. "OR

Bug#803255: exim4: segfault upon reading /etc/email-addresses

> In case it is important, I can reproduce the bug when recompiling from > source as well. The segfault is gone after applying the patch available here: https://bugs.exim.org/show_bug.cgi?id=1708#c10 Thank you -- Sylvain

Bug#803255: exim4: segfault upon reading /etc/email-addresses

> It is reproducible, please see https://bugs.exim.org/show_bug.cgi?id=1708#c4 In case it is important, I can reproduce the bug when recompiling from source as well. # cat /tmp/email-addresses root: h...@example.com # cat /tmp/exim.conf begin rewrite *@foo.bar

Bug#803255: exim4: segfault upon reading /etc/email-addresses

Hello > I have forwarded the issue upstream to > where a some > questions came up. Would you mind following up there? > > * Is the bug reproducable via 'exim -brw root' > If it is, a debug run (/usr/sbin/exim4 -d+rewrite+expand -brw root) > would help.

Bug#803255: exim4: segfault upon reading /etc/email-addresses

> Could you provide a backtrace, please? There you go: (gdb) run -v sylv...@gromi.net < /tmp/echo_subject Starting program: /usr/sbin/sendmail -v sylv...@gromi.net < /tmp/echo_subject [Thread debugging using libthread_db enabled] Using host libthread_db library

Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting

Hello (But Sylvain, it would be great if you could run with earlyprintk too to confirm the output). I will try to do this tonight. One question though: from a test point of view, do you agree that booting from a 3.12 or 3.13 kernel sent over tftp (and I assume pushed to RAM, seeing how fast it

Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting

2014/1/14 Martin Michlmayr t...@cyrius.com: * Sylvain LÉVÊQUE sylvain.leve...@gmail.com [2014-01-14 12:13]: (But Sylvain, it would be great if you could run with earlyprintk too to confirm the output). I will try to do this tonight. One question though: from a test point of view, do you

Bug#726138: Extra info about the css files

Hello Here is the output for the three css files I have a copy of. The one before upgrading: filename before_upgrade.css length 4837344 extent 0: record length 98317 extent records used 96819 extent records free 1498 extent 1: record length 49157 extent records used 35037