I agree, it’s also unmaintained. Let’s take it out.
Roelof
(Author and original packager)
Von meinem Mobiltelefon gesendet.
> Am 02.12.2022 um 10:38 schrieb Andreas Tille :
>
> Am Thu, Dec 01, 2022 at 11:39:47PM +0200 schrieb Adrian Bunk:
>> [1] contains a patch from a Debian porter, but
I changed the compiler settings as suggested. This is only a hotfix to
enable the package-build again. Because the underlying problem might be
safety relevant (BOF) I added an entry to upstream's issue tracker and
added a note to inform debian, when the compiler can be reverted to more
strict
Wow, thanks a lot Jurica ! I'll take care of it asap.
On 17.01.2016 19:52, Jurica Stanojkovic wrote:
User: debian-m...@lists.debian.org
Hello,
I have found that changing -fstack-protector-strong to -fstack-protector (for
test or for entire source) does make this issue disappear on mipsel.
Damn. If I execute it in qemu (Mips), all tests pass. Cannot reproduce
it (yet).
debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0"
Thanks Aurel32
On 26.10.2015 21:47, Roelof Berg wrote:
I wonder what might be the best way, to test my fix for MIPS.
I wonder what might be the best way, to test my fix for MIPS. Esp. I
wonder how the Debian build server operates. I would normally assume a
cross-compile - but the tests seem to be executed on a real MIPS. Might
it be emulated ?
On 28.09.2015 22:53, Roelof Berg wrote:
I assume, the software
I assume, the software is ok but the test automation is not. The
'algorithm under test' gives a bit fuzzy results depending on the
multicore calling order and depending on numerical rounding issues.
Therefore the automated tests accept results within a range of plausible
values. Seems that
Probably related to the latest GCC update, I'll take care of it.
8 matches
Mail list logo
