On Mon, 20 May 2024, Mechtilde Stehmann wrote:
> There are several with FTBR. I found that the day of the *.poms s a date from
> 1970.
I’ve had a look at this. The files have various, *differing*,
timestamps within the month of January 1970, which in itself
is not proper.
It’s not a t64-related
Wookey dixit:
>And it worked beatifully. Thanks.
Nice!
>I'll try doing openjdk-20 next.
You’ll want 21 as 20 has not got the t64 treatment.
gl hf,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Hi Wookey,
>OK, got those. but that's just binaries. It was the source changes I
>was looking for (or did I misunderstand and you didn't actually make
>any of those?),
Yes, I did not make any source changes. These were the last binaries
from before the t64 transition (I downloaded the .deb files
On Wed, 27 Mar 2024, Wookey wrote:
>I looked at this last week, but got stuck because openjdk-17's
>build-deps included graphviz
Build-Depends-Indep: graphviz, pandoc
You don’t need that. Use dpkg-checkbuilddeps -B, or manual
inspection of the .dsc (packages.d.o does show the difference
between
On Tue, 26 Mar 2024, Jeffrey Walton wrote:
>Nothing beats a native compile in your basement.
Yes, definitely.
>> Do they run stock Debian armhf?
>
>So the CubieTruck is embarrassingly down level:
Oofff…
>The Wandboard is doing better:
Right, close enough anyway.
>I don't mind shipping to Eur
Hi Jeffrey,
I’m answering back from the $dayjob address because Googlemail
cannot communicate with normal mailservers.
>I can send you two dev boards, if you want them. The first is
>Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is
>CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I trie
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
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
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
Arnd Bergmann dixit:
>Yes, that sounds reasonable in principle.
OK, good. I’ll do that then when I’m caught up with dayjob work.
>I've tried to come up with a minimal test case like
Meh, I’m just going to write a main.s ;-) I like assembly.
Also, less surprises there. GCC is…
bye,
//mirabilos
Arnd Bergmann dixit:
>so this is enabled on all SMP-enabled kernels but can be disabled
>on uniprocessor Armv7 builds, which would be broken here.
I guess the buildds would be running some kind of stock Debian
kernel from, probably, stable or oldstable. (The latter may be
problematic but I’ve see
outlook 1017537 some armel buildds are misconfigured and lack SWP emulation
thanks
Dixi quod…
># if __ARM_ARCH__ < 6
> swp r0, r1, [r2]
># else
And this, after some research, is it. This is needed for armel, which
is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at least
Dixi quod…
>In case this makes anyone immediately think of whatever it is:
Code looks right enough (with an explanation of why this only
fails on armel but not on armhf which is perfectly fine):
$ cat arm/__testandset.S
#include "arm-features.h"
FUNC_START __testandset
mov r2,
>but it ALSO fails in a bullseye chroot, so this is possibly not related
In case this makes anyone immediately think of whatever it is:
(gdb) r
Starting program: /home/tg/dietlibc-0.34~cvs20160606-el-11/debian/unittests/ttt
Program received signal SIGILL, Illegal instruction.
__testandset () at
outcome 1017537 fails on porterbox/bullseye as well, suspect 64-bit host to be
an issue
tags 1017537 + help
thanks
In contrast to armhf, which works fine on the porterbox (amdahl; abel,
which I normally use, is currently down) for me, this one also fails,
but it ALSO fails in a bullseye chroot, s
Arnd Bergmann dixit:
>The way the FPU type gets selected in gcc changed with recent versions,
>this was intentional and won't be reverted but it did break packages that
>used the old method.
Hmph.
>In most cases, it's sufficient to pass
>-march=armv7-a+fp instead of -march=armv7-a to pick the ri
Arnd Bergmann dixit:
>I tried cross-building it myself now and found the same issue with
>an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as
>
>/usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as
>-v -march=armv7-a -mfloat-abi=hard -meabi=5 -o bin-arm/
Arnd Bergmann dixit:
>-march=armv7-a+fp instead of -march=armv7-a to pick the right
“instead of”
We pass nothing there, and we need a solution (or two distinct
ones) for armel and armhf.
bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what abou
tags 1017538 + help
forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
thanks
Hi Sebastian,
instead of filing a bug with the information we already have…
>arm/__longjmp.S: Assembler messages:
>arm/__longjmp.S:9: Error: selected processor does not support `vldm
>ip!,{d0-
Arnd Bergmann dixit:
>gcc changed the way that you pass the floating point instruction set,
>so instead of -march=armv7-a one should now pass -march=armv7-a+fp
>to pick a target CPU that includes vfpv3-d16 FPU.
But we pass neither!
$ git grep -F armv7- | wc -l
0
>My guess is that in your case t
Jeffrey Walton dixit:
>If I recall correctly... Debian now uses ARMv7 for a default, which
>enables NEON in the compiler. Automatically enabling NEON based on
>ARMv7 is a GCC 11 change.
Hmmh. But armhf used ARMv7 by default before, too, if I’m not mistaken.
>(I thought Debian's armel went away r
Dixi quod…
>did something change wrt. compiler defaults on armhf recently?
armel also FTBFS with SIGILL in the testsuite.
So something changed incompatibly between 2019-11-10 and now
in the ARM toolchain. But what, and how can I get this to work
again?
Thanks in advance,
//mirabilos
--
Solange
Hi,
did something change wrt. compiler defaults on armhf recently?
The almost unchanged upload of dietlibc todays fails on armhf
(albeit on an arm64 buildd):
gcc -D__dietlibc__ -I. -isystem include -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-ffile-prefix-map=/<>=.
-specs=/usr/share/dpkg/no-pie-com
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
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
Steve McIntyre dixit:
>>That seems like a bad idea to me, tbh. There will be people who won't
>>notice that the meaning of debian-ports@ has changed, and who will try
>>to use it with its old meaning.
>favour of the existing behaviour. If anybody does use try to use it
>that way in future, the ne
On Fri, 17 Jul 2015, John Paul Adrian Glaubitz wrote:
> On 07/17/2015 09:31 AM, Thorsten Glaser wrote:
> > using build profiles breaks debian-ports architectures, all of them:
>
> What exactly is a build profile in this context?
> > Build-Depends: […] libgpac-dev (>= ⌦
Hi *,
using build profiles breaks debian-ports architectures, all of them:
http://buildd.debian-ports.org/status/package.php?p=x264
│Dependency installability problem for [33]x264 on alpha, hppa, m68k, sh4,
sparc64 and x32:
│
│x264 build-depends on missing:
│- empty-dependency-after-parsing
wd
Alexander Wirt dixit:
>Could you please (technically) summarize what needs to be done from
>listmaster side?
1. Remove whatever debian-ports@l.d.o is right now
2. Create a new debian-ports@l.d.o mailing list which
works just like the other regular lists
3. Announce the new debian-ports@l.d.
Steven Chamberlain dixit:
>On 05/09/14 18:39, Steve McIntyre wrote:
>> * Remove the confusion: turn debian-ports into a separate *normal*
>>mailing list, announce it and let people subscribe to it [...]
>
>That sounds perfect IMHO. It could be used for general discussion about
>porting, upco
(excluding d-release for what they hatingly call “debian-ports spam”)
Matthias Klose dixit:
>I would like to see some partial test rebuilds (like buildd or minimal chroot
Haven’t tried yet, but Helmut Grohne does automated rebootstrapping of
some ports using what he can get his hands on, and he
John Paul Adrian Glaubitz dixit:
>On 05/02/2014 10:05 PM, Helge Deller wrote:
>>> This needs to be addressed on d-i side; we need better support
>>> for the dpo 'unreleased' suite there.
>>
>> Sounds not very simple or clean.
>> How did you solved that on m68k then?
Not yet. I’m not a big friend
Helge Deller dixit:
>Can such a package be uploaded to debian master ftp if I go through
>the standard ITP process?
No.
>If not, is there a way to make this happen on debian-ports somehow?
Not in unstable, only in unreleased. We have the same problem
on m68k with e.g. bootloader packages.
Thi
Michael Banck dixit:
>I am not sure which thread you are meaning, and in general, I think
>discussing random Linux kernel config options on -ports is off-topic.
Indeed, that wasn’t the intent of this thread. I’ve continued
that particular discussion on debian-68k.
My intent in _this_ thread was
Finn Thain dixit:
>Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was
See the discussion in the thread before this message.
>CONFIG_EARLY_PRINTK disabled?
It was never enabled. And that’s what you get when you let
a BSD guy whose Linux experience dates back to 2.0.3[3-6]
(and some 2.4.
Dixi quod…
>Hi $maintainer,
>
>can we still get CONFIG_EARLY_PRINTK=y and
>CONFIG_SERIAL_PMACZILOG=n into 3.12 before it hits unstable?
This was, of course, not integrated into src:linux before the
3.12.6-1 upload. (Which by the way autobuilt, meaning we have
build logs ☻ instead of me building i
jhcha54008 dixit:
>Custom mini-repositories for installation
>-
>
>One may download the missing packages from
>http://snapshot.debian.org/archive/debian-ports.
Indeed, but – as I said – the regular debian-ports archive is
also weekly snapshotted, and Auré
Michael Schmitz dixit:
> your finding that packages from both unstable and unreleased are needed is
> correct (along with the complication that some may not be availabe at any
> given
> time).
There’s another problem: even in the main Debian archive, “unstable”
is *not* guaranteed to be debootst
Helge Deller dixit:
>We noticed, that when we manually binmnu-upload packages, which are
>already in the *same version* on debian-ports, then debian-ports ACCEPT
When you binNMU packages you add a +b1, +b2, … suffix to their
versions. ITYM porter upload?
>those packages, but if we then try to ap
John Paul Adrian Glaubitz dixit:
>On 11/24/2013 12:47 AM, John David Anglin wrote:
>> It should be going up now.
>
>So, the buildds are already up and running? Shouldn't they be showing
>up on buildd.debian-ports.org [1]?
I think I saw buildd uploads for hppa on incoming.d.o this week.
Paul Wi
Don Armstrong dixit:
>These are the list of ports that I see:
Question is, where do you see them?
>avr32
This one got removed even from debian-ports for several
reasons.
>sh
I think there's sh4 but not just sh.
Looking at the buildd pages is probably the best idea.
Combining https://buildd.d
Niels Thykier dixit:
>Then there are more concrete things like ruby's test suite seg. faulting
>on ia64 (#593141), ld seg. faulting with --as-needed on ia64
And only statically linked klibc-compiled executables work on IA64,
not dynamically linked ones. I’ve looked into it, but Itanic is so
massi
Package: dose-distcheck
Version: 3.1.3-5
Severity: normal
Hi,
I get the following error with dose-debcheck in both wheezy and sid:
tglase@tglase:~ $ dose-debcheck --deb-native-arch=m68k --failures --explain >> $?"
Fatal error in module deb/debcudf.ml:
Unable to get real vers
Package: edos-distcheck
Version: 1.4.2-13+b1
Severity: normal
tglase@tglase:~ $ = 3.3.2-2~)
1|tglase@tglase:~ $
Architecture: all
Replaces: python3 (<< 3.3.2-4~)
Depends: python3:any (>= 3.3.2-2~)
Breaks: python3 (<< 3.3.2-4~)
Description: Debian helper tools for packaging Python libraries and ap
Steven Chamberlain dixit:
>Come to think of it, it must take a day or more for m68k to rebuild
>eglibc. This is a more serious problem than resources needed by
Kernel takes a day now (on the fastest VMs), eglibc 3 days,
gcc 5 days (since gcj got folded into it; add another day or
so once gnat wi
Matthias Klose dixit:
>> I’d like to have gcj at 4.6 in gcc-defaults for m68k please,
>> until the 4.8 one stops FTBFSing.
>
>please send a patch.
For gcc-defaults? I think that one is trivial…
For gcj? I did not take Compiler Design in what two semesters
of Uni I managed until I ran out of mone
Steven Chamberlain dixit:
>Before that can be changed, I think the gcc-defaults package expects
>package version (>= 4.8.1-2) whereas m68k still has only the 4.8.0-7 you
>uploaded.
Right. That’s because gcj FTBFSes.
>You will also first need newer binutils (>= 2.23.52) which is still in
>the bui
Matthias Klose dixit:
>The Java and D frontends now default to 4.8 on all architectures, the Go
>frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.
I’d like to have gcj at 4.6 in gcc-defaults for m68k please,
until the 4.8 one stops FTBFSing.
From me nothing against switching C/C++
Matthias Klose dixit:
>Currently java bindings/packages are built for all architectures, however some
>architectures still use gcj as the (only available) Java implementation, and
>some OpenJDK zero ports are non-functional at this point, and Debian porters
>usually don't care about that. So the
maximilian attems dixit:
>ok I see, thus #634890 has rc severity.
No, last time I’ve thought armhf were RC just because they ended up
being in the main archive I was told off; armhf and s390x still are
not RC. But “we” should process it as if it were RC, probably.
On the other hand, my Latin is
maximilian attems dixit:
>I don't know if klibc-utils provided binaries do work on armhf?
In this case, sh and sh.shared don’t work on armhf, either with
or without thumb. The Debian package builds without thumb.
>(there is a bug report for tegra, but that maybe very specific)
No, that isn’t it
Hi,
we’re currently seeing trouble with klibc on several architectures,
cf. http://www.zytor.com/pipermail/klibc/2012-May/003277.html and
armhf is being one of them, when using klibc to compile mksh-static
with it.
I can look into it (asked zumbi for build-deps in a sid chroot on
harris already),
Matthias Klose dixit:
>GCC 4.7 is now the default for x86 architectures for all frontends except the D
>frontends, including KFreeBSD and the Hurd.
How are the plans for other architectures?
The m68k status (which obviously can’t influence the release decisions)
is as follows: gcc-4.7 builds, la
Dixi quod…
>please schedule manual builds of the following packages on
>armhf alpha hppa buildds (or equivalent):
>
> dietlibc (0.33~cvs2008-1) experimental; urgency=low
Please use 0.33~cvs2008-2 (just uploaded) instead,
it should fix hppa. (Please build in a clean chroot,
with sbuild or
Arnaud Patard dixit:
>Thorsten Glaser writes:
>>> mksh (40.2-3exp1) experimental; urgency=low
>>
>> Never mind that on ARM… #633479 bites again.
>>
>> Gah. How to work around that bug? Or can please
>> someone prod Doko to fix? ;-)
>
>L
Dixi quod…
> mksh (40.2-3exp1) experimental; urgency=low
Never mind that on ARM… #633479 bites again.
Gah. How to work around that bug? Or can please
someone prod Doko to fix? ;-)
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bone
Hi,
please schedule manual builds of the following packages on
armhf alpha hppa buildds (or equivalent):
dietlibc (0.33~cvs2008-1) experimental; urgency=low
mksh (40.2-3exp1) experimental; urgency=low
Note that mksh (40.2-3exp1) dep-waits on dietlibc (>= 0.33~cvs2008-1)
The reason fo
Matthias Klose dixit:
> At this point, pretty well after the GCC 4.6.0 release, I would like to avoid
> switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce
> maintenance efforts on the debian-gcc side, even before the multiarch changes
Porters side, too. I’m okay with kee
69 matches
Mail list logo
