Forgot…
>tg@fish:~ $ ./a.out
struct baa {
int a;
long long b;
};
#include
#include
int main(void) {
struct baa stct;
#define t(w,s) printf("%s\ts=%u\ta=%u\n", #w, \
(unsigned)sizeof(s), (unsigned)__alignof__(s))
#define o(w,m) printf("%s\ts=%u\ta=%u\to=%u\
On Fri, 15 Nov 2024, Finn Thain wrote:
>On NetBSD/m68k I get,
>
>sizeof(struct baa) == 16
>__alignof__(long long) == 8
>__alignof__(struct baa) == 8
That makes sense.
>> Isn't the alignment of a struct the largest alignment of any of its members?
>
>Sometimes...
I think I have a rough idea why
On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:
>On i686 (i.e. gcc -m32 on amd64):
>
>__alignof__(long long) = 8
>
>but
>
>sizeof(struct baa) = 12
>__alignof__(struct baa) = 4
>
>???
>Isn't the alignment of a struct the largest alignment of any of its
>members?
I’d say yes. Probably th
(please keep my debian.org address in the distribution list,
not the mirbsd one, as it has better chance to interact with
other mail providers out there for this… except Googlemail,
which, of course, is no proper mail provider and actively
disrecommended because it fails to collaborate for FOSS wor
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
>I think it makes sense to go through these anyway and annotate
>them to document and enforce the alignment we actually want
That would be good in general, yes. I’d personally argue for
using explicit padding members (please do NOT use __unused,
rather __
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
>On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
>>Right. And I don't think the problem is going to go away. One solution
>>that is sometimes raised is better tooling. I'm not sure how that would
No. You don’t understand the problem: applications are be
Finn Thain dixit:
>That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
>case on my Linux/i686 system. 4 != 8:
>
>struct baa {
>int a;
>long long b;
>} foo;
That struct is just 12 bytes for you then?
That’s possible on i386 but almost nowhere else, and has multi
Finn Thain dixit:
>> >That seems to imply that someone requires that those packages are
>> >ported.
>>
>> Yes, we do. Rust especially is killing the entire FOSS ecosystem.
>>
>> These all are conditio sine qua nōn when it comes to continuing
>> Linux/m68k, as a whole.
>
>I think that's overstat
On Sat, 26 Oct 2024, Finn Thain wrote:
>> The following packages require 32-bit alignment:
>>
>> - mold
>> - LLVM
>> - gccgo
>> - Qt5 (several packages affected)
>> - Qt6 (several packages affected)
>> - OpenJDK (all versions)
>> - Python >= 3.13
>> - Rust
>
>That seems to imply that someone requi
On Sat, 26 Oct 2024, Andreas Schwab wrote:
>Already basic things like struct stat64 will break.
OK. Then, flag day, I guess.
How do we model this in Debian. Rename libc to libc6.1 and
conflict with libc6 to force no coïnstallability, rename the
architecture from m68k to… something else, or…?
Bu
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
>as m68k has supported 32-bit alignment through the "-malign-int"
>switch for a long time.
That switch constitutes a fundamental ABI change, even if
the effect is limited.
Question is, do we need a kernel change for this at all?
Is there anyt
Dixi quod…
>>I’ll recompile with re-enabled alignment on the missing base
>
>Seems to be only one.
>
>--- src/hotspot/share/memory/allocation.hpp~ 2024-04-12 23:52:54.0
>+
>+++ src/hotspot/share/memory/allocation.hpp2024-04-12 23:52:56.0
>+
>@@ -276,7 +276,7 @@ clas
Dixi quod…
>I’ll recompile with re-enabled alignment on the missing base
Seems to be only one.
--- src/hotspot/share/memory/allocation.hpp~2024-04-12 23:52:54.0
+
+++ src/hotspot/share/memory/allocation.hpp 2024-04-12 23:52:56.0
+
@@ -276,7 +276,7 @@ class CHeapO
Dixi quod…
>>(This is what I found trying to build openjdk-20, but it’ll be
>>needed in 21 as well. Even getting to this point took 13½ days
>>already…)
>
>And turns out that this isn’t the cause.
>
>In 17, we’ve got src/hotspot/share/memory/allocation.hpp to
>align all CHeapObj, StackObj, Metaspa
Dixi quod…
>(This is what I found trying to build openjdk-20, but it’ll be
>needed in 21 as well. Even getting to this point took 13½ days
>already…)
And turns out that this isn’t the cause.
In 17, we’ve got src/hotspot/share/memory/allocation.hpp to
align all CHeapObj, StackObj, MetaspaceObj, e
Source: openjdk-21
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
Please add the following patch e.g. to debian/patches/m68k-support.diff
for more making implicit alignment assumptions (here by the futex
syscall) explicit:
--- src/hotspot/os/linux/waitBarrier_linux.hpp~ 2024-04-12 18:2
retitle 1067207 mesa: [m68k] switch statement too large, needs
-mlong-jump-table-offsets
tags 1067207 + patch
thanks
>Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should
That did it. I built with…
APPEND CFLAGS -mlong-jump-table-offsets
APPEND CXXFLAGS -mlong-jump-table-offsets
Source: glade
Version: 3.40.0-5
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
As hinted in another ticket, please extend the exclusion of
webkit [not ia64 kfreebsd-any] to also exclude m68k. (You
probably can remove kfreebsd-any at the same time.)
I’m still looking into the B-D of src
any idea?
Source: google-perftools
Version: 2.15-3
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
In file included from src/common.h:43,
from src/common.cc:43:
src/base/basictypes.h:390:5: error: #error Could not determine cache line
length - unknown architec
Source: llvm-toolchain-17
Version: 1:17.0.6-9
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
Attempts to build llvm-toolchain-15 (needed for qt6) and 17 (which
is apparently what everyone should switch to, but 16 might also need
it) fail at configure stage:
The ta
>Please use libseccomp-dev B-D only on architectures where it
>actually exists (i.e. is not in state uncompiled).
>
>webkit2gtk is a B-D for glade, which is depended on by the
>Xfce stack, as far as I can tell, whose t64 transition this blocks.
Might be useful to consider not depending on webkit2g
Source: webkit2gtk
Version: 2.42.5-2
Severity: important
Justification: ftbfs on d-ports architectures
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
Please use libseccomp-dev B-D only on architectures where it
actually exists (i.e. is not in state uncompiled).
webkit2gtk is a B-D for
Dixi quod…
>I was able to strace this:
[…]
>openat(AT_FDCWD, "/etc/__db.sasldb2", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0660)
>= 3
>fcntl64(3, F_GETFD) = 0
>fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
>get_thread_area() = 0xc0501500
>get_thread_area()
Package: sasl2-bin
Version: 2.1.28+dfsg1-5
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
The openldap build on an m68k qemu-user buildd cannot install sasl2-bin in the
chroot:
[…]
Setting up pkg-config:m68k (1.8.1-1) ...
Setting up libsasl2-2:m68k (2.1.28+dfsg1-5) ...
Setting up libs
:48.0 +0100
+++ jack-audio-connection-kit-0.126.0/debian/changelog 2024-03-21
02:03:21.0 +0100
@@ -1,3 +1,9 @@
+jack-audio-connection-kit (1:0.126.0-2+m68k) unreleased; urgency=medium
+
+ * Only B-D: libffado-dev if jackd1-firewire is built
+
+ -- Thorsten Glaser Thu, 21 Mar 2024 02
Source: openssh
Version: 1:9.7p1-2
Severity: important
Justification: FTBFS on d-ports arch
Tags: ftbfs
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
On m68k, gcc-13 currently ICEs when -fzero-call-used-regs=used is
used (see #1066891) in moduli.c, packet.c, etc. but the configury
dete
Source: mesa
Version: 24.0.3-1
Severity: important
Justification: FTBFS on d-ports arch
X-Debbugs-CC: t...@mirbsd.de, debian-68k@lists.debian.org
Tags: ftbfs
mesa currently FTBFS on m68k with:
[…]
cc -Isrc/nouveau/headers/libnvidia_headers.a.p […] -o
src/nouveau/headers/libnvidia_headers.a.p/mes
Source: graphviz
Version: 2.42.2-9
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
librsvg has become extremely unportable, and so only a subset of
architectures have it:
amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x
loong64 powerpc ppc64 sparc64
Please whitelist the li
John Paul Adrian Glaubitz dixit:
>However, it turns out that my approach is wrong and upstream has already used
>a different approach for firebird4.0 [2], although I haven't tested that on
>m68k yet.
>> [2] https://github.com/FirebirdSQL/firebird/pull/234/commits
(use https://github.com/Firebird
Source: qt6-base
Version: 6.4.2+dfsg-21.1
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
firebird3.0 is not available on m68k because it invalidly assumes…
struct foo {
char a;
int b;
};
… that b is 32-bit aligned in this struct from implicit padding,
which neither C n
Dixi quod…
>Is there a chance your team could fork the old python-cryptography
>source package (3.4.8-2) and do something like:
Apparently, pyopenssl needs to also be forked as it wraps the above
and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust
version of python-cryptography ☹
bye
Source: fsverity-utils
Version: 1.5-1.1
Severity: important
Justification: RC for Debian-Ports
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
Recent versions of fsverity-utils (larger than 1.4-1~exp1 anyway)
have a Build-Depends-Arch on pandoc; however, pandoc is an extremely
unportab
Package: libc6
Version: 2.36-8
Severity: normal
Tags: ipv6
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
This error occurred first during curl’s configure in a chroot with
libc6 2.37-15.1, but I could also reproduce it on a build host with
libc6 2.36-8 as well, and on an even older hos
Jérémy Lal dixit:
>Anyone had experience with the version 3.3 to 38.0 migration ?
>Maybe the API didn't change that much.
We cannot go past 3.4 because newer versions (starting at 38)
have a hard dependency on rust stuff.
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich m
Jérémy Lal dixit:
>While I'm very much concerned about architectures and compatibility,
>it seems that for python-cryptography, it's a sinking boat:
>The end of a very discussion dates from february, 2021 - 3 years ago:
>https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406
Ouch
Hi,
we have still the situation that the current python-cryptography,
having rather heavy rust ecosystem dependencies, cannot be built
on some debian-ports architectures.
This situation is not likely to go away:
• some ports are unlikely to meet the dependencies soon
• new ports won’t meet them
John Paul Adrian Glaubitz dixit:
>Hi Miro!
Please do not use Googlemail when attempting to collaborate with
OSS maintainers. I don’t know whether you will get this eMail from
me but I will almost certainly not get your response, and Google
are fully to blame for that.
>On Tue, 2023-05-23 at 13:0
Hi Adrian,
>When Matthias re-uploaded openjdk-8 for bootstrapping Kotlin, I just
>rebuilt the last working version 8u171-b11-2 [1] for m68k and uploaded
>it.
I see.
>I tried fixing the issue you are seeing but just gave up at some point
OK, thanks for the confirmation.
>because I was hoping th
Hi,
I’m resurrecting openjdk-8 in sid because it’s apparently needed for
bootstrapping other (JVM-based) languages/tools, and it doesn’t work
for m68k. (This is probably no problem as we have openjdk-11 there.)
Does anyone know about this? (This used qemu-user-static in case that
matters.)
[…]
gm
her case
>of prodding maintainers (and, perhaps, looking whether it can’t be
>fixed in qemu as well).
I prodded maintainers, see below, but the latter looks like it’ll be
needed.
-- Forwarded message --
From: Thorsten Glaser
Message-ID:
To: Aurelien Jarno
Cc: 916...@bugs.deb
Michael Tokarev dixit:
> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>>>17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
>>>> On 9/16/20 8:42 PM, Thorsten Glaser wrote:
>>>>> John Paul Adrian G
John Paul Adrian Glaubitz dixit:
>That’s been fixed upstream and can be configured with the
>qemu-binfmt.sh script and the option “preserved=yes”.
$ locate qemu-binfmt.sh | wc
0 0 0
Also, why didn’t you fix that on the m68k and sh4 qemu buildds then? ;-)
Meow,
//mirabilos
--
Package: qemu-user
Version: 1:5.1+dfsg-4
Severity: important
X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org
I’m attaching a test program that does the following:
• if argv[1] is "-" it just outputs argv[0] and argv[1]
• otherwise it also execve(2)s argv[1] with its argv[0] set to "meow
Finn Thain dixit:
>I think it would be helpful to everyone if nocheck could be avoided where
>possible. I wonder where is that possible.
I’d prefer if it could be added only for problematic packages, or
done in porter uploads, but on the buildds not for all packages.
>Which architectures are usi
Control: severity -1 wishlist
Control: tags -1 wontfix
John Paul Adrian Glaubitz dixit:
>On m68k and sh4, the buildds are currently configured to pass "nocheck"
Precisely for this reason, some packages in the archive ignore that
on these architectures.
Without the testsuite we cannot reliably b
John Paul Adrian Glaubitz dixit:
>Looks like the bug is no longer reproducible:
Thanks; in this case, we can close the bug.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
This was fast! The m68k and hppa stuff is already grabbed.
Remaining:
> Accessories:
> • assorted PC keyboards and mice
> • assorted monitors
> Sun:
> • Sun Ultra5
>
> x86(?):
> • 2x Targa PC Series II (some Pentium-based towers)
Not much info about these. The picture of the tower on
https://ww
Hi everyone,
a good friend of mine left behind a couple of old hardware
which is currently located in a basement in Lippstadt, Germany;
it’s scheduled for being dumped into the trash soon (we’re
talking about $smallnum weeks) but it was offered to me.
I don’t currently need this, but here’s a lis
Debian Bug Tracking System dixit:
>> tags 925358 + unreproducible
Funnily enough, the problem persists on the qemu buildd.
https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=m68k&ver=57-2&stamp=1569456240&raw=0
I guess I’ll have to set up a qemu environment and track
this down…
bye,
//mi
Package: linux-base
Version: 4.5
Severity: important
Control: affects -1 initramfs-tools
Some time between 4.1.0-2 and 4.19.0-3, m68k kernels switched
from vmlinuz-* to vmlinux-*:
-rwxr-xr-x 1 root root 5933276 Feb 11 16:55 vmlinux-4.19.0-3-m68k*
-rwxr-xr-x 1 root root 5933284 Mar 15 02:16 vmlinu
Hi Adrian,
>Could you point me to the actual error message so I know how the reproducer
>looks like?
sure: it’s the
Total failed: 3 (3 unexpected)
in the build log, and before that:
FAIL ../../debian/mtest.t:mtest-external
Description:
Minitest: can run an externa
>fail
>
>virtual memory exhausted: Cannot allocate memory
I should probably give-back it, but packages failing when the
buildd has “only” 768 MiB RAM are a problem. (Yes, I know, I
can set ARAnyM to give it more nowadays, but the host doesn’t
have more either.)
We probably should tackle this some
John Paul Adrian Glaubitz dixit:
>On Mon, Jun 26, 2017 at 03:03:04PM +1000, Finn Thain wrote:
>>> I use NatFeat disc only, though, not the ncr controller.
>>
>>There is no working ncr controller provided by aranym, just a stub for
>>one, sufficient to fool certain operating systems.
Aaaah, o
Finn Thain dixit:
>On Mon, 26 Jun 2017, John Paul Adrian Glaubitz wrote:
>> Which can be worked-around by adding
>> "initcall_blacklist=atari_scsi_driver_init" to the kernel command line.
>> The buildd "mama" is running 4.11 with that work around.
Looks like it:
Linux ara5.mirbsd.org 4.9.0-3-m68k
Package: src:linux
Version: 4.9.30-2
Severity: important
I cannot boot Linux 4.9, but 4.1 still works. (I think 4.3 also failed,
but I had autoremoved that already.)
ARAnyM console log for failed build:
-cutting here may damage your screen surface-
ARAnyM 1.0.2
Using config file: 'buildd
John Paul Adrian Glaubitz dixit:
>actually re-packed by me by replacing libjvm.so from Andreas Schwab's build
Ouch.
Does diffing the disassembly of (parts of) that give any meaningful
information? Maybe rather the individual .a files in libjvm.a?
As for the main problem, no idea. I don’t even k
Guillem Jover dixit:
>> Yes, but they *do* break anything that
>> - acts on the CFLAGS (and LDFLAGS) variables
>> - uses klcc or other compiler wrappers that don't understand -specs
>> - uses clang or pcc or whatever other compilers
>
>The default dpkg build flags have always been tied to the spec
clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures
thanks
Guillem Jover dixit:
>> I cannot build openssl1.0 any longer. Downgrading all binary
>> packages from src:dpkg to 1.18.10 makes the build succeed.
Interestingly enough, src:openssl
Lisandro Damián Nicanor Pérez Meyer dixit:
>Andreas: did you made the patch? Has it been submitted upstream? What's the
>license for it? I can't just blindy apply it without that info.
Patches usually share the licence of the patched files;
as it is, there’s nothing copyright-relevant in it anyw
Andrew Kelley dixit:
>https://github.com/andrewrk/libsoundio/issues/7
Yes well, I’m only the guy whose autobuilder is trying to build
the Debian package. So if you require specific versions of the
dependencies, version them.
>On Wed, Feb 10, 2016 at 8:57 AM, Thorsten Glaser wrote:
ch one is better. Either will work.)
>Let.us.just.fix.the.code. Dang!
BTDT.
>> On Feb 4, 2016, at 10:41 PM, Thorsten Glaser wrote:
http://www.afaik.de/usenet/faq/zitieren/
bye,
//mirabilos
PS: You’re wrong on the timing, too. I can write an eMail like
that extremely quickly, it’s
Finn Thain dixit:
>On Wed, 3 Feb 2016, Thorsten Glaser wrote:
>> > > > > > > [package maintainers] don't care about dpo
>> [...]
>> Multiply this by the amount of packages I deal with, because almost no
>> two use the same bugtracker.
>>
Source: botan1.10
Version: 1.10.12-1
Severity: serious
Justification: Policy §4.9.1
X-Debbugs-Cc: debian-68k@lists.debian.org
Your package FTBFS with nocheck in DEB_BUILD_OPTIONS:
debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
dh_auto_test -- check
LD_LIBRARY_PATH="/usr/l
John Paul Adrian Glaubitz dixit:
>On 02/03/2016 09:42 PM, Thorsten Glaser wrote:
>> Yes. I have to localise which upstream it is, which bugtracker
>> they have, fight that bugtracker software’s crappy webinterface,
>> register, wait until their mail times out due to greylist
John Paul Adrian Glaubitz dixit:
>Because it takes too much effort to report such a bug in the
Yes. I have to localise which upstream it is, which bugtracker
they have, fight that bugtracker software’s crappy webinterface,
register, wait until their mail times out due to greylisting and
them usin
John Paul Adrian Glaubitz dixit:
>why not just upstream your patch?
Upstream, for me, is Debian.
bye,
//mirabilos
--
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). S
743]Thorsten Glaser ; Date: Mon, 11
Nov 2013 23:00:02 UTC; Severity:
minor; [744]Found in versions xorg-server/2:1.14.99.3-1,
xorg-server/2:1.16.0-2; Filed 2 years and
83 days ago; Modified 1 year and 151 days ago;
/me guesses they fucking don’t care about dpo (some, like jcrist?(e
fail
make[1]: *** No rule to make target 'test-2.7-stamp', needed by
'override_dh_auto_test'. Stop.
This is an FTBFS when nocheck is defined. (But then… due
to #700730 we should probably mark it as Not-For-Us anyway.)
Sascha Steinbiss dixit:
>> Since this is a C++ package for which compilation can be quite =
>> resource-intensive and take a long time, it could be that the build
>> = machine might not be up to it. Maybe you know more about the
>> involved = machines and whether there might be any chance to get t
fail
CMakeFiles/emos_sp_shared.dir/__/interpolation/hirlsm.F.o: In function
`hirlsm_':
/<>/interpolation/hirlsm.F:486:(.text+0x90e): relocation truncated
to fit: R_68K_GOT16O against `.LC21'
John Paul Adrian Glaubitz dixit:
>What about other kernels versions inbetween? I'm running a
Dunno, I only use Debian kernels, but ISTR reporting a similar
issue for 4.2.
bye,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (317 (338) bugs: 0 RC, 221 (236) I&N, 96 (102) M&W
Dixi quod…
>Package: linux-image-4.3.0-1-m68k
>Version: 4.3.3-5
>Severity: important
>X-Debbugs-Cc: debian-68k@lists.debian.org
>
>This kernel does not boot on ARAnyM any more. Log:
[…]
linux-image-4.1.0-2-m68k (= 4.1.6-1) boots fine, though,
so my buildd is still running again ☺
bye,
//mirabilo
fail
virtual memory exhausted: Cannot allocate memory
John Paul Adrian Glaubitz dixit:
>> Even Andreas (whose message I read too late) said it was a known
>> kernel bug (can it be fixed, pretty please?).
>
>Yes, a bug in the m68k kernel. Which means something that needs
No, a bug in the Linux kernel. It also appears on amd64.
That is, Linux/amd64, n
John Paul Adrian Glaubitz dixit:
>On 12/06/2015 04:52 PM, Thorsten Glaser wrote:
>> John Paul Adrian Glaubitz dixit:
>>
>>> And it's not that Aranym doesn't have it's own problem. I'm still seeing
>>> the issues with
John Paul Adrian Glaubitz dixit:
>And it's not that Aranym doesn't have it's own problem. I'm still seeing
>the issues with kswapd consuming over 50% CPU time from time to time
>slowing down the emulated machine quite notably.
Someone told me on SO the other day that he had this bug on
an amd64 s
Dixi quod…
>Laurent Vivier dixit:
>>Le 21/11/2015 13:07, Andreas Schwab a icrit :
>
>>> Does that include the FPU emulation?
>>
>>I don't know: FPU emulation is on 96 bits (in fact 80...) and can have
>>some bugs (I didn't fix the NaN format for the moment).
>
>In this case, e.g. Python interpreter
John Paul Adrian Glaubitz dixit:
>You *do* need X11 for the initial setup as Aranyms fbcon driver is
>read-only and doesn't allow any keyboard input. This has been much of
>a show stopper really.
No, just a disc image with ssh set up.
>I have had arguments with my boss over this more than once a
John Paul Adrian Glaubitz dixit:
>For Aranym, I first need to run a X server to set up the system. You
>cannot configure Aranym headless.
Nonsense. I did so on the Xen domU in which the ARAnyM VM ara5 runs.
>Secondly, you need a manual, more complicated network configuration as
… well yes…
>To
Laurent Vivier dixit:
>Le 21/11/2015 13:07, Andreas Schwab a icrit :
>> Does that include the FPU emulation?
>
>I don't know: FPU emulation is on 96 bits (in fact 80...) and can have
>some bugs (I didn't fix the NaN format for the moment).
In this case, e.g. Python interpreters and related things
Hi porters,
I’ve just
>fail
’d the following packages due to…
>ruby currently broken on m68k
– giving the list so we can easierly give-back them once fixed:
• libselinux_2.4-3
• ruby-debian_0.3.9+b1
• ruby-fcgi_0.9.2.1-1+b1
• ruby-fusefs_0.7.0-4+b1
• ruby-http-parser.rb_0.6.0-3+b1
• ruby-leve
fail
debian/rules:155: recipe for target 'install-ruby-stamp' failed
fail
There is a bug in libtorrent here: it unconditionally uses
atomics on 64-bit quantities, which GCC doesn’t guarantee:
configure:18050: g++ -o conftest -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -g -DDEBUG -pthread-I/usr/include
-D_FORTIFY_SOURCE=2 -Wl,-z,relro co
fail
This is likely to be a new option -notimestamp added to
OpenJDK’s javadoc tool but not GCJ’s.
find jpathwatch-java/src -name *.java -and -type f -print0 | xargs -s 512000 -0
/usr/lib/jvm/default-java/bin/javadoc -locale en_US -classpath
:debian/_jh_build.jpathwatch -d debian/_jh_build.java
Andreas Schwab dixit:
>pcre 8.37 worksforme ootb.
Ah right, there was something… I think they downgraded it for some
reason and have yet to upgrade it again.
Thanks,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (330 bugs: 0 RC, 233 I&N, 97 M&W, 0 F&P)
‣ src:dash (118 bug
fail
testsuite STILL fails
as this appears in the “32-bit” library (I assume UCS-4 here) only
this smells like another of the bogus alignment assumptions issues
Philipp Kern dixit:
>> Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is.
>
>Unfortunately it is not being run on the same host as dak either.
Hm, rmadison then. What does packages.d.o/sid/binpkgname use? (On the
other hand, that’s often quite behind…)
bye,
//mirabilos
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> and testing), so the only way to be certain what binNMU number to use is to
> check manually. In practice what actually happens is that people forget about
Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is.
I’ll have a look
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> >> Ah, cool – so we have only to patch this tool to automatically
> >> use the highest number per batch on all affected architectures
> >> (or even to use the highest number if all architectures would
> >> be touched, but that’s probably an unre
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> wanna-build does, yes, but at least the Release Team tend to use the "wb"
> wrapper tool which automatically works out the next free number on each
> architecture.
Ah, cool – so we have only to patch this tool to automatically
use the highest number p
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> I didn't say once per arch. I said once per package, which is worse. I
> normally
> schedule binNMUs for several dozens packages. Multiply that by several
But you need to look the number up anyway? The wanna-build
--binNMU parameter gets the n
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> I can go back to scheduling binNMUs for release architectures only, or for ANY
> -x32. But I don't have the time to look at every architecture and determine
> which one needs a binNMU and which one has already done it. Anyway if your
OK. In thi
Hi,
whoever is scheduling binNMUs now should do so with a little
bit more care, please.
Case in point, frameworkintegration – x32 already was rebuilt
against the new Qt API and did not need the additional binNMU.
Case in point, some OCaml binNMUs were done recently (within
the last month), to re
fail
/«PKGBUILDDIR»/Source/JavaScriptCore/assembler/MacroAssembler.h:62:2: error:
#error "The MacroAssembler is not supported on this platform."
Aurelien Jarno dixit:
>As you can see the file is corrupted (though it is correctly
I cannot see that. I compared the file with (I just had it
lying around here) a .changes for mksh on x32, line by line,
and (other than that the mksh file had an additional Closes:
line) the keys are identical. I
Hi,
why does this error happen?
The file in question is:
begin 664 /var/lib/buildd/upload/slony1-2_2.2.4-2_m68k.changes
M+2TM+2U"14=)3B!01U`@4TE'3D5$($U%4U-!1T4M+2TM+0I(87-H.B!32$$S
M.#0*"D9O3$M,@I":6YA3$M,BUD;V,@<&]S=&=R97-Q;"TY+C0M3H@0VAR
M:7-T;W!H($)E3$M,B`M(')E<&QI8V%T:6]N('-Y3UM961I=6T*("X*
Christian T. Steigies dixit:
>about CNAME. How are your buildds handling email, you have no problems like
>that (static IPs, proper MX records?)?
The buildd has *no* external IP at all, but an MX RR pointing to
a server with static IP (as a general rule, any server listed in
any MX RR *SHOULD NOT
Christian T. Steigies dixit:
>Interesting, but with this set wrong, everything behind the @ is not cut-off:
>From: m68k Source Builder
That's because it treats 'sbuild\@garkin.steigies.net' as the
localpart of the eMail address and adds its own domain, as
opposed to FQDN, there, and steigies.ne
Christian T. Steigies dixit:
>I tried to set this in .sbuildrc as (do I need to escape the @?):
>$mailfrom = 'm68k Source Builder ';
>
>which shows up in the email headers wrong:
>From: m68k Source Builder
It’s 99.9% sure that you have a CNAME there somewhere.
And voilà…
tg@blau:~ $ host gark
1 - 100 of 1161 matches
Mail list logo
