Re: Builds not reproducible on armhf
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 JDK bug: I tested…
import java.io.*;
class T1 {
public static void main(String args[]) throws IOException {
File sf = new File("T1.java");
File df = new File("T1.out");
System.out.println(sf.lastModified());
InputStream is = new FileInputStream(sf);
OutputStream os = new FileOutputStream(df);
byte[] data = new byte[32768];
int nbytes = is.read(data);
os.write(data, 0, nbytes);
os.close();
is.close();
df.setLastModified(sf.lastModified());
}
}
… on armhf with OpenJDK 8, 17 and 21 (11 needs t64-transitioning).
Given the range of January 1970…
$ TZ=UTC date -d '1970-01-31T23:59:59Z' +%s
2678399
$ TZ=UTC date -d @2678399000
Sun Nov 15 23:43:20 UTC 2054
… it is entirely possible that someone confused time_t and
Java millis, so the timestamps are off by a factor of 1000.
-rw-r--r--···0·root·(0)·root·(0)·1415·1970-01-06·08:03:05.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
-rw-r--r--···0·root·(0)·root·(0)·1415·1970-01-03·13:27:14.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
-rw-r--r--···0·root·(0)·root·(0)·1416·1970-01-09·01:36:03.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/vinnie-debian.pom
-rw-r--r--···0·root·(0)·root·(0)·1416·1970-01-04·21:40:23.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/vinnie-debian.pom
$ for t in 1970-01-06T08:03:05 1970-01-03T13:27:14 \
1970-01-09T01:36:03 1970-01-04T21:40:23; do \
TZ=UTC date -d @$(TZ=UTC date -d "${t}Z" +%s)000; \
done
Fri Aug 10 11:23:20 UTC 1984
Tue Jan 4 13:53:20 UTC 1977
Sat Feb 1 16:50:00 UTC 1992
Mon Sep 8 01:03:20 UTC 1980
Okaaay… So, maybe not so much. I *was* guessing something with
DEB_SOURCE_EPOCH vs. project.build.outputTimestamp, but that’s
apparently not it either.
So I fear someone’ll have to dig through all the various Maven-
related source packages…
FWIW, the 517-day-old .deb currently in the repo has…
-rw-r--r-- root/root 1415 2022-12-17 18:36
./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
… which matches Sat, 17 Dec 2022 18:36:19 +0100 from d/changelog,
so something something reproducible-builds is still suspect.
Good luck with that,
//mirabilos
--
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
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 :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
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 unchanged) with just control.tar.xz/control changed to allow installation given the relevant libraries were already rebuilt for t64. > but actually having an openjdk binaries is very useful >too to satisfy the self-dependency without more faff. Yes, that was their purpose. >I'm no java expert so if anything breaks or it gets more complicated >than 'get the right build-deps in (with care for t64-libs) somehow' I >will indeed be asking questions :-) Right. I’m no expert either, though :/ >> What was the actual problem with uploading the images you built? Just >> not having any corresponding source? Or something more complicated? > >Answering my own question: There have been a couple of new openjdk-17 >uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build >(17.0.10+7-1) is out of date. Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already moved to 17.0.11~7ea.orig.tar.* >So I now have all the pieces (on armhf, not checked armel yet but >hopefully it matches) Depends, but 'apt install /tmp/*.deb' will tell you ;-) >The build failed: > >An exception has occurred in the compiler (17.0.10). Please file a bug against >the Java compiler via the Java bug reporting page (https://bugreport.java.com) >after checking the Bug Database (https://bugs.java.com) for duplicates. >Include your program, the following diagnostic, and the parameters passed to >the Java compiler in your report. Thank you. >java.io.UncheckedIOException: java.nio.file.FileSystemException: .: Value too >large for defined data type > >Don't worry about this. It's a an issue to do with building for 32 bit >inside qemu on a 64-bit machine. I'll stop doing that and use real >hardware :-/ Ouch. I was just wondering which filesystem you used, but yes, there’s that known combined qemu/kernel/libc issue which cbmuser is also constantly running into. I think switching to… sgixfs I think? also makes it work, but I’m not sure. https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c73 sgixfs and btrfs, yeah, ext4 is problematic. But apparently, LFS should fix this but Java is again special in that it’s still problematic there. Were you using qemu-user? qemu-system has its own kernel and “should” be fine, modulo the usual qemu issues. Real hardware is better (for many architectures even necessary). Good luck, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
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 adep and idep but not the profiles, unfortunately, and these can be key in ordering decisions). >another blocked chain with ghostscript,cups and libgtk2 conflicting >about their t64 status. You do need the t64 versions of all that, and the latest openjdk-17 fixed the issue with libcups2 (Ubuntu initially forgot to move that to t64 while Debian did that early, and openjdk-?? followed the former). > apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed You should get that rebuilt, yes. On the other hand, if everything else is falling into place, it’s not a problem for apt to uninstall itself just in that one build chroot ☻ > libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be > installed > libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed > libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be > installed These are fine. > libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed Force that away; nothing from this is actually used during the openjdk build in a way sufficient to impact the build. >But dose now says there is a solution, unlike last week. Oh, dose… right… here I was checking all of them manually ^^ (which did give me a better impression of where to break the cycles and what to upload earlier). >> openjdk-21 is in a similar situation, build-depending on itself, while >> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. >I presume the same, but don't actually know how old a java you can use >to bootstrap each newer java. Is it always just one version? AIUI it’s always just one version; I know it was so until 17, but I don’t think this has loosened (I asked in IRC, but got no answer until I went to sleep). >> Presumably once we have a single OpenJDK version that is installable, >> it would be possible to step through 18,19,20,21 building each version >> with the previous one. You’d have to patch them to both address the t64 issues and make it imply nocheck (or quinn-diff doesn’t pick it up as installable). It’s best to get at least 17 and 21 (which AIUI is the one we’ll want for trixie?) built this way. I think, unless users complain, we can these days go without 8 and probably even without 11. (You’d be surprised at the amount of users wanting 8, so I now provide those in a private repo of mine, but so far amd64/i386-only has sufficed for those. For the purposes for which 8 is still in sid, dropping armel and armhf will _most likely_ also suffice; ELTS still wants them, but rebuilt in jessie and stretch chroots so there is no re‐ bootstrapping to be done.)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
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 Europe if you don't mind paying the VAT. I >think you will be the fourth or fifth Debian maintainer I've sent >hardware to. So sending from outside the eurozone, that can get tricky fast (depending on the value, they also want import duties on top), I think that might just be overkill for a oneshot helping out. Let’s see if I can get an account on a project box first, or work with someone who has. (I’m not intending to add going into ARM development on top of what I already try to balance… right now, I’m mostly helping m68k through t64, so Adrian does not burn out, he’s also got sh4 and powerpc to do, and the whole rest of d-ports with the mini-dak trouble of keeping old binary packages around.) But I do thank you for that offer. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
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). Both work, but I >don't use them much anymore. I've mostly moved on to Aarch64. That is certainly an option, if you don’t want them any more and want to ship them to .de, although it’ll likely take longer than just getting access on a suitable project machine. RAM is tight on them, but with swap the compiling should work. Both seem to have serial console, good. Do they run stock Debian armhf? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
-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 tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.
I did the observation that doko changed their source packages
to have the binaries Recommend instead of Depend on the libraries
in question. (Unfortunately neither before the transition started
nor coordinated with the openjdk-8 maintainer (me).)
I downloaded the latest binary packages of openjdk-{8,11,17,21},
changed all references to the libraries in question to refer to
their t64 counterparts, bumped the version number, repacked the
.deb files and updated the .changes files as if to do a binNMU.
After uploading, I used wanna-build to set the priority high so
they get rebuilt before someone considers using them.
mini-dak accepted these, but dak requires that the archive has
the corresponding source available, and since new versions (the
part before the Debian hyphen-minus) had already been uploaded,
it did not have them at hand any more either.
The rebuild process succeeded, as openjdk building itself does
indeed not use the libraries in question (or at least those
parts of their interface that are time_t-relevant).
I don’t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I’m not in the situation of throwing the
.debs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we’re using #debian-ports on OFTC for the
d-ports architectures and I couldn’t find out where to write to
for arm{el,hf}, so this mail of yours comes at a good time ;-)
The options for the armel/armhf porters are to either get the
.debs from me, install them in a chroot, and then the other B-D,
and rebuild the packages, or to use dpkg --force-depends to
install the dependencies (which makes it hard to use apt to
install the other ones unless you also edit /var/lib/dpkg/status
by hand first, something I was already used to from my reviving
m68k back in 2012–2015) into the chroot then rebuild there.
I will gladly help if it’s made possible for me to help. This
cannot be done on a porterbox because it’s still impossible to
either install arbitrary .debs into a chroot there or to obtain
root in the chroot to be able to force installation in the absence
of some Depends.
So if you have a fast armhf box or two, ideally with chroots
already made for sid, which you don’t mind temporarily giving
me root on, I’m in, otherwise I’ll answer questions from these
doing that work if needed.
I *think* 8/11/17/21 are the only versions we need to handle.
This does save us from having to rebootstrap this.
bye,
//mirabilos
- --
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８ ☕☂☄
iQIcBAEBCQAGBQJmA0vXAAoJEHa1NLLpkAfg0ZQQAI7P7qoVfADQrrsuNHAShvTB
lRvuK1br7bHRmqUx89dDwjOG1k0Xji3X3OURZldlhPCk99SJxQP3DLoCX5cmCzIA
IDyq+GoxREjJ/uyb4b6/qTAgSh7ZdRqxEfbVLsukL1i+wRs6dNw2Wg64i/R538jE
+yncg7zMyrWSA+3815i7BRfdMZBEk9E1qgW3hlnhueVfgANuyBLzzJchSstjunqE
0OcIukVQ30HaWaALmAfGcl7lcfM0sUFXL+EVpA8aBsVWNzZHtMIPnmI+yx8X4NOo
BOkfcYbPI928VZ/91meibSb9FXk8ShnO+zv+gU6dX74RlVoqOIeg6UQ/r2Cy+Up9
ssnksqTWTSkw1/n9bRNNiU8/O4kI5xV6FCUk2CaOsk+diQfXpoga50TR6DRM52tp
mjtBetkI1qK9vA0Y1VS+KoPp/FDYwFBKXiU3Jax9L7koaT5wGCurILqNTbDGVe19
2nmnphBUeIFniPByiItSEv7jH9GgxZyrwRvonYYpDXNeXFa0ymTNzKzrIG2ZqMrz
LcELgtIb6OD+WDYajUMOlTRBj2N9rFodruKyMcdUfc4so3OoFnS3cOdBvWBk/NdX
sFRgES39Ak5xgA3f4hP2ba03KZOFH2iIT3M8ZtZhH7eOIdhErKIUG0t6hxpWFdiV
ntE5WUlefRxovhbTOXKa
=KoS1
-END PGP SIGNATURE-
Bug#1067026: graphviz: please build without librsvg except on rust platforms
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 librsvg usage restricting it to these architectures. This is a ports-only change, release architectures are not affected, but it’ll help tremendously.
Re: python-cryptography vs. stainless steel ports
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, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#1066832: fsverity-utils: hard Build-Depends on unportable package pandoc
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 unportable package written in a hard to port language. Please split the package so that the part that requires pandoc is done in an arch:all build. Normally, pandoc is needed only for documentation, which is often easy enough to split off in a -doc binary package, which can then move to B-D-Indep and be built on amd64 or whatever hosts. Thanks, //mirabilos
Re: python-cryptography vs. stainless steel ports
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 meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: python-cryptography vs. stainless steel ports
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. cbmuser also has hopes for rustc_codegen_gcc, but I believe that quite a way off for regular use in Debian yet and won’t hold my breath. So, perhaps at least do palliative care for the 3.8-based package in the meantime? Porters can help, but we don’t know the python ecosystem well. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
python-cryptography vs. stainless steel ports
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 at first even if they may meet them later (riscv64 and loong64 now meet them) For the t64 transition, I *think* I can just binNMU the last version that worked and porter-upload that, but that’s not a workable long-term solution, especially when python transitions come, etc. Is there a chance your team could fork the old python-cryptography source package (3.4.8-2) and do something like: • rename its python3-cryptography binary package to python3-cryptography-rustless or something • let that Provide python3-cryptography in the same version Making python3-cryptography-rustless available on all arches has the benefit that people can test that their code will work on ports arches without having to bother installing one of them. I’m not entirely sure that having python3-cryptography-rustless Provides python3-cryptography, then other packages B-D/Depends python3-cryptography will work; IIRC, there was something about the first alternative must not be virtual and buildds won’t use second+ alternatives. In that case, we’ll instead need the python3-cryptography-rustless source package to build a second binary package python3-cryptography either as arch:all but in a lower version than the python-cryptography’s (if that’s okay), or as arch:any on just the affected architectures (which will end up being an annoying to maintain whitelist) that Depends python3-cryptography-rustless, to keep things installable on the buildds. With this in unstable proper, debian-ports will have a much easier job, and maintainers (both of the python3-cryptography ecosystem/packages and of software using it) can more easily test things work, and your team can apply whatever new policy changes, dh-* helpers, etc. to the 3.4.8-based package, and backport bugfixes, etc. (and perhaps there’s even an upstream fork?). The arches currently split as: • alpha 3.4.8-2 • hppa 3.4.8-2 • hurd-amd643.4.8-2 • hurd-arm64unknown, probably 3.x • hurd-i386 3.4.8-2 • ia64 3.4.8-2 • loong64 41.0.7-5 • m68k 3.4.8-2 • powerpc 41.0.7-3 • ppc64 41.0.7-5 • sh4 3.4.8-2 • sparc64 41.0.7-5 • x32 38.0.4-4 (x32 seems to be lagging in the rust department, too…) Since this exists mostly to help d-ports, it would be fine to open an RC bug against it early to prevent it from showing up in releases, if desired. Thanks for considering, //mirabilos, helping out m68k for the time_t transition again -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: Bug#1017537: armel buildd misconfiguration
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 -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: Bug#1017537: armel buildd misconfiguration
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 seen it.) Or, at least, I hope they do.
>Most likely, the buildd is running a default debian kernel and has
>the compile-time options enabled, but has it disabled at runtime.
>
>Can you find out if /proc/sys/abi/swp exists on the system, and
Only on the porterbox amdahl; it exists and is 0.
The same would then be valid for porterboxen: for it to be a viable
armel porterbox, this must be set to 1.
Do you think it would be worth compiling a VERY tiny program from
execute_before_dh-auto-build that just runs an swp instruction, and
if that fails, issue a message pointing to your message? I’m doing
something similar for mksh wrt. the existence of /dev/{tty,pts,ptmx}
but here it can obviously only be done if not cross-compiling (but
that’s not a problem because the tests can only run then either).
Thanks,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
armel buildd misconfiguration (was Re: Bug#1017537: dietlibc: FTBFS on armel)
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 one buildd listed does not have this enabled, breaking the armel ABI. Please ensure that only hosts with working SWP emulation run armel. (Can I reassign this bugreport to the buildd? Does it have a virtual package in debbugs?) Until then, I guess I’ll keep giveback’ing dietlibc on armel until it builds… bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Re: Bug#1017537: dietlibc: FTBFS on armel
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, r0 mov r1, #1 # if __ARM_ARCH__ < 6 swp r0, r1, [r2] # else 1: ldrex r0, [r2] strex r3, r1, [r2] cmp r3, #0 bne 1b # endif RET FUNC_END__testandset bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: Bug#1017537: dietlibc: FTBFS on armel
>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 arm/__testandset.S:7 7 swp r0, r1, [r2] (gdb) bt #0 __testandset () at arm/__testandset.S:7 #1 0x000113d4 in __pthread_lock (lock=lock@entry=0x25054 <_main_thread+20>) at libpthread/pthread_spinlock.c:84 #2 0x0001052c in __thread_find_ (pid=) at libpthread/pthread_internal.c:98 #3 0x00010578 in __thread_self () at libpthread/pthread_internal.c:127 #4 0x00010280 in malloc (size=32) at libpthread/pthread_sys_alloc.c:20 #5 0x00010124 in main () (gdb) info r r0 0x25054 151636 r1 0x1 1 r2 0x25054 151636 r3 0x0 0 r4 0x0 0 r5 0x25054 151636 r6 0x0 0 r7 0x1e8481201 r8 0x1016 r9 0xfffef684 4294899332 r100xfffef68c 4294899340 r110xfffef67c 4294899324 r120x1420 sp 0xfffef3c0 0xfffef3c0 lr 0x113d4 70612 pc 0x11480 0x11480 <__testandset+8> cpsr 0x6010 1610612752 fpscr 0x0 0 (gdb) disas Dump of assembler code for function __testandset: 0x00011478 <+0>: mov r2, r0 0x0001147c <+4>: mov r1, #1 => 0x00011480 <+8>: swp r0, r1, [r2] 0x00011484 <+12>:bx lr End of assembler dump.
Bug#1017537: dietlibc: FTBFS on armel
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, so this is possibly not related to a toolchain change. I think I’ll have to track down a 32-bit ARM machine and test-build it there. I recently got gifted a Raspbery Pi v1.2 so that’d be running armel anyway, so I guess it’s installing Debian on that thing for me now. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
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 right >instruction set. There’s no “instead of”, though. So basically, I now need to add -march=… to CFLAGS in the package when compiling for either of armel and armhf. Which value do I use for armel, which for armhf (the one you gave is for armhf, I think)? bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Re: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
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/__longjmp.o >longjmp.s > >where the old one would pass an extra -mfpu=vfpv3-d16. Is my expectation that, for any given platform (armel, armhf, arm64), that a default invocation of the system compiler adds the correct flags not good? >However, with arm-linux-gnueabihf-gcc-12, it appears to work fine again. Sounds like a bug in gcc-11 instead then? (Why has this then not hit more packages?) >I also see that the Makefile attempts to detect the host architecture, but >fails to recognize armv8 hardware as arm. What hardware and toolchain >environment was the failing build on? debian/rules inspects DEB_HOST_ARCH and passes MYARCH to the upstream Makefile so this ought to DTRT…ish — arm64 is passed as aarch64, and all other *arm* are passed as arm (though we don’t carry armeb or the pre-EABI arm any more so that’s probably also fine). Note that #1017537 (on armel) and #1017538 (on armhf) probably are, if not the same thing, at least related. bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
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 about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Re: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
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-d15}' in ARM mode
… you could maybe have considered answering the question I posed
on the Debian ARM mailing list about *why* it fails because nothing
related to ARM was changed in the package or code.
So something in the toolchain(?) must have changed since the last
successful build (what?) which we need to locally revert.
Thanks in advance for any help,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: vldm on armhf?
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 the compiler gets the wrong target CPU >and passes that down to the assembler, which then refuses to build >using FPU instructions. Hmm. So rebuild with -v on a porterbox? bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Re: vldm on armhf?
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 recently). Nope, still very much active and listed as release architecture even. (And even if not, debian-ports do exist, and we want to support as many as possible.) I’m not an ARM programmer though. The port was done by multiple others and IIRC even slightly diverges from what upstream currently has, as we collected bugfixes in Debian which upstream ignored. So the specific details of which subarchitectures have which instructions are a bit beyond my paygrade (I do know about the differences between arm, armeb, armel, armhf-raspian, armhf-everyoneelse and arm64 though, just on a somewhat higher level). bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Re: vldm on armhf?
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 man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
vldm on armhf?
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-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wall -fno-pie -specs=/usr/share/dpkg/no-pie-link.specs
-Wl,-z,relro -Wl,-z,now -no-pie -pipe -nostdinc -D_REENTRANT
-Os-fomit-frame-pointer -fstrict-aliasing -W -Wall -Wextra -Wchar-subscripts
-Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused
-Wredundant-decls -Wshadow -c arm/__longjmp.S -Wa,--noexecstack -o
bin-arm/__longjmp.o
arm/__longjmp.S: Assembler messages:
arm/__longjmp.S:9: Error: selected processor does not support `vldm
ip!,{d0-d15}' in ARM mode
make[2]: *** [Makefile:206: bin-arm/__longjmp.o] Error 1
The code in question is:
>#include "arm-features.h"
>
>FUNC_START __longjmp
>mov ip, r0
>movsr0, r1
>moveq r0, #1
>#ifndef __SOFTFP__
># if __ARM_ARCH__ >= 6
>vldmip!, {d0-d15}
[…]
We don’t have __SOFTFP__ and we do have __ARM_ARCH__ >= 6,
obviously. So, why does this suddenly fail?
Thanks in advance,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
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 specific >language compiler version currently marked as the default (for C that >would currently be gcc-6). Sure, but we do have other compilers and compiler wrappers in the archive, and packages are using them. >As long as gcc enables PIE on a subset, there will be need to inject >some form of specs on either subset of those arches, either on >hardening=+pie or on hardening=-pie, pick yout poison. :( […] >> Either are *much* better than the current way. > >Well you and me both, I'm just adapting the dpkg-buildflags to the >current gcc situation. :/ This sounds to me like we should reassign this to GCC (and remove all the… well, “offending”, no offence intended, code from dpkg). >Having a subset of architectures is a pain for maintainers as they True, so GCC should just enable it on all architectures where it at all works. >Well I think we should be enabling all hardening flags directly in >gcc, but now that we have the specs files I guess it would not be >too bad to enable them just in dpkg, but I agree either would be >preferable. :/ OK, thank you. bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
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 (1.1) works, so… >So, I think I'll reassign this to openssl1.0, if no other feedback … this is probably legit. But I would *still* like to raise another point. >Those specs files should make it possible to build stuff with PIE 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 Worse, they break *differently* on whether… >Precisely to make the behavior consistent on all architectures, dpkg >enables PIE (conditionally if no other flags marks it as to be >disabled) on all architectures were gcc has not enabled this by >default. … that. And that is just plain wrong. Either dpkg should inject -specs= stuff on all architectures or on none. Differing like this just invites hidden and hard to track down bugs. Please get an agreement with the GCC maintainer on how to proceed from here. Personally, I’d still prefer for GCC to behave as on other systems, i.e. not to enable PIE by default, and to have it done completely within dpkg, but I can *also* live with it being done exclusively in GCC. Either are *much* better than the current way. >if no other feedback is provided showing that this is a problem in >dpkg itself, such as PIE not working at all there, and a request to >disable it for x32 in dpkg as non-functional. This can be done just as well on the GCC side. >Also BTW the gcc maintainer asked that porters >interested could request PIE to be enabled by default in gcc. What difference does it make on whether GCC or dpkg enables PIE? The two last quote sections make it clear that any architecture that currently has PIE enabled in dpkg should have it enabled in GCC in the first place. (Did dpkg enable that on porters’ requests? It does not look like that to me. This smells like overstepping boundaries.) tl;dr: I don’t care as much _which_ of GCC xor dpkg does it, as long as only one does it. FFS, just enable it on all of them unless known to absolutely not work; that’d still be better than the current mess. Thanks, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: binNMUs: please exercise some care
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 -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: binNMUs: please exercise some care
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 at the code, maybe on this weekend. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 unreasonable amount of code > >> change). > > > > Sorry, aren't you saying the same thing in both cases? If not, can you > > rephrase > > or expand that? > This won't help when we have to schedule a binNMU on one or two architectures > and not all of them. That’s why I made the distinction. The change to the tool can be done by taking the highest version number across the _listed_ or _all_ architectures. (The listed ones is probably better.) On Fri, 23 Oct 2015, Adam D. Barratt wrote: > Well, except you only really want to do it for libraries that are ma:same, as > that's the only case where it actually matters and otherwise you're > pointlessly losing versions. Right, but it’s not as if losing versions would have any bad impact. > It's also not quite that simple, even working things out by hand - see #599128 > for example. Hm, I’m still under the impression that the +bN suffix to the Debian version of the package in the archive is the authoritative source for what binNMU version a package currently has, as that’s taking porter uploads into account which is a requirement. If the current code doesn’t do that I consider it a bug which must be fixed (at the same time, or before doing this change), which makes it more tricky, yes. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 per batch on all affected architectures (or even to use the highest number if all architectures would be touched, but that’s probably an unreasonable amount of code change). Where’s the source code to that tool? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 number to use as argument. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 this case, scheduling them is probably better. > buildds are fast enough that they already rebuilt things, then maybe > rebuilding > them again is not such a big deal... This is probably true for x32, yes, but I was concerned about M-A libraries not being coinstallable. For example, the harfbuzz library currently has one +b more than all others, making trouble for my desktop system (x32+i386 M-A). In that case, it wasn’t even because the rebuild was done twice, but, because another rebuild before the current (shared) one was necessary. How about, scheduling them all at once, but using the same version number across arches when doing it (i.e. the largest)? > That wasn't me. But I'll try to spread the word about --extra-depends, as I > agree it's useful to avoid this. I didn't use it much in the past when I just Okay, thanks a lot! Also, thanks for the response. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
binNMUs: please exercise some care
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 rebuild against the new compiler version, but that version was not yet built on m68k. (You can set extra Build-Depends and use that to version them, to make sure that, while you have the comfort of scheduling them all at once instead of in several batches, they only happen after their prerequisite has been done.) Unfortunately, I have no idea how to find out who was the person scheduling them, so this generic message will have to suffice. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Time to change the debian-ports "list"?
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 new list will most likely be the best place >for their mail to go... I agree, the new ports list would probably be the better place; mails and people can still be directed elewhere, but this would take less time from people to whom the message “probably” should not have gone in the first place. (Take my recent message, for example – while the ports multiplicator was not wrong per se, the new list would have been even better. If needed I could have added individual architectures’ lists, but I’d only do that if urgent.) Adrian dixit: >I'm in favor of the old design because I think it's important to havw a >list which can be used to make announcements about important issues >that all porters should be aware of. Even then, the new design is better (active porters will likely subscribe to the new list, users won’t, but they’re getting the “spam” right now), and for archive-wide things, d-devel-announce is the place to go anyway. bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1507222113000.27...@herc.mirbsd.org
Re: using build profiles breaks debian-ports
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 (>= ⌦0.5.0+svn4288~),⌫ ▶0.5.0+svn4288~) > > ,◀ […] bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.20.1507171033500.11...@tglase.lan.tarent.de
using build profiles breaks debian-ports
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 wdiff shows: Version: ⌦2:0.146.2538+git121396c-2⌫ ▶2:0.146.2538+git121396c-3◀ Build-Depends: […] libgpac-dev (>= ⌦0.5.0+svn4288~),⌫ ▶0.5.0+svn4288~) ,◀ […] So this means that because someone added the build profiles thing, wanna-build (or something else in the component stack) on dpo can no longer calculate B-D installability for those packages, which sorta defeats the purpose of adding it. bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.20.1507170928540.11...@tglase.lan.tarent.de
Re: Time to change the debian-ports "list"?
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.o so that people can subscribe to it; document that there is no longer an address to reach *all* ports but that people should eMail the individual ports’ lists (and cross-post if needed, but only to the amount needed), and that the new debian-ports@l.d.o instead is a mailing list for discussion about a) debian-ports.org infrastructure b) porting Debian in general c) questions related to setting up a Debian port, including wanna-build, buildd, etc. Thanks, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1409101858240.4...@herc.mirbsd.org
Re: Time to change the debian-ports "list"?
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, upcoming new ports, or any ports that don't quite merit having >their own mailing list yet. Agreed, all that plus the dpo infrastructure, buildd and wanna-build related setup (possibly for both dpo and the main archive), etc. >>"debian-cross-ports" or "debian-architectures" or something. > >I'd prefer not to have it, or have to sign up to it as a porter. It'd >probably get more spam than useful mail. Agree. >I can't think of a reason to mail *all* ports that wouldn't be >appropriate for debian-devel-announce; or if your mail only concerns a >few ports it should be convenient to cross-post to the relevant ports' >lists only. Fully agree. bye, //mirabilos -- ncal.c: In function 'parsemonth': warning: comparison between pointer and integer • ↑ hab da „in function parselmouth“ gelesen ICH AUCH! • Ich hab gerade gedacht "Häh? Wie, hab da parselmouth gelesen ... steht da doch auch :o?" -- too much fanfic… -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1409051936000.7...@herc.mirbsd.org
Re: [m68k] preparing for GCC 4.9
(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 said m68k was the best-(cross)bootstrappable port, and was using gcc-4.9 for it, so there are probably at least no ICEs. If Helmut can publish the *.deb files that fall out of such a (cross) rebootstrap, we could try debootstrapping (natively, in ARAnyM) from them, then boot (a VM) into them, to check basic usage. This sounds pretty few work. Other than that… we’ve built src:gcc-4.9 now, which means that at least the C/C-- part survives the three-stage bootstrap AFAICT. >packages) for other architectures. Any possibility to setup such a test rebuild >for some architectures by the porters? Afaics the results for the GCC testsuite >look okish for every architecture. … that runs it. I have no idea how to set up such a test rebuild setup, but we have somewhat clonable VMs (and a VM base image that “just” needs to be dist-upgraded to latest sid before using it), so “anybody” can do that for m68k (provided they install the aranym package from sid, as it contains FPU emulation bugfixes required by Python 3.5 at least). Also, I’d be interested in a way to run GCC’s testsuite against an installed compiler, i.e. without taking the five days needed for the bootstrap (plus adding dejagnu and removing disabling the testsuite from the package rules) again. bye, //mirabilos -- Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405081543370.28...@herc.mirbsd.org
Re: How to get d-i udeb packages for hppa-only back into unstable?
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 of d-i myself (but recognise its need, of course), so I’ve not done any work in that area. Some debootstrap patches exist, and IIRC Wouter has done/planned something on the d-i side, but he also stopped due to lack of time. >We didn't yet :(. You have to partition the disk manually and copy >a root filesystem onto it. Either that or debootstrap, yes. >I agree with Thorsten, this is a fundamental problem with Debian ports >that needs to be addressed, especially when you look at the stats how ACK. >Maybe this problem gets more attention within the rest of Debian when >sparc, which has recently been dropped from testing, will move to the >ports side. Since there are still many people running Debian on sparc, >there might be an incentive to solve this problem. Absolutely no: everyone who was using sparc post-etch will just change to sparc64, and people using a real sparc (as opposed to sparc64) have… other venues… open to them which are OT on this list ;-) >>The only simple way I see is then to set up an own repository (cloned >>from debian-ports), add the packages there and then instruct the >>installer to load the installation packages from there. This is at >>least how I got it to work sucessfully once. No, you don't need that. You can work with unstable+unreleased, if you just tell it to merge the Packages lists in the proper place, and if the mirror carries both. That being said: it is not, generally, possible to install (using either debootstrap or d-i) from “unstable”, even in Debian proper, due to missing dependencies, library transitions, etc. (which the dpo-minidak bug that doesn’t keep libraries around for as long as they’re used makes only worse). We need some sort of “testing”-lookalike suite, and a way for ports to opt-in to have packages from “unreleased” migrate into it. (This is for ports staying on dpo. Ports bootstrapping on dpo and intending to get into the main archive from there will, of course, need to have zero packages in “unreleased”, and as such, their “testing”-alike (I’d call it a different name though, and ideally one per arch¹) would have only packages from unstable too.) ① if for no other reason that, even when taking only from unstable, (binary) package version will differ, adding the need to track different versions of source packages too bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405022200020.22...@herc.mirbsd.org
Re: How to get d-i udeb packages for hppa-only back into unstable?
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. This needs to be addressed on d-i side; we need better support for the dpo 'unreleased' suite there. Sorry, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;) -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405021909120.22...@herc.mirbsd.org
Re: maintainer communication
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 to get a discussion among
debian-ports.org users started for best practices of how
to communicate with package maintainers in Debian. Sorry
for being unclear there. I had hoped for hints ☺ since I
know my communication skills lack somewhat.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh"). [aus dasr]
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1312232212380.2...@herc.mirbsd.org
Re: maintainer communication
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.3) do the Debian/m68k Linux kernel config, instead of someone who actually knows about this. I did warn y’all back then. Now we got a config, and we can incrementally improve it. >how it can help when it is downstream of the kernel developers. Eh? Parse error. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312231645470.2...@herc.mirbsd.org
maintainer communication (was Re: Debian kernel regression, was Re: Modernizing a Macintosh LC III)
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 it in cowbuilder manually on a – possibly faster – VM.) The request to the GCC maintainer to somehow make autoconf regenerate some more configure scripts, to fix the -fpic/-fPIC problem, was, of course, also not integrated. I think we need to file bugs in the BTS for each of these instances in the future, instead of trying to communicate with the maintainers directly. I hate it, because I like to talk to humans more, and some people on the Debian side hate it too (“because debports is not Debian”), but… *shrug*. Tell me if you have a better idea. Or anything else to comment on this matter. To clarify: this is *not* intended to make package maintainers show in a bad light, rather the contrary, trying to improve things. I can understand that things that are not in the BTS are likely to be forgotten (in fact I forgot a suggestion how to do/fix something too, due to falling ill last week and not writing it down e.g. in the bug). Thanks, //mira“still on antibiotics but recovering”bilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312231011210.24...@herc.mirbsd.org
Re: debootstrap and debian-ports
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élien can persist them TTBOMK (like etch-m68k was). I’ve got a manually created mini-repository for m68k, but experience shows acceptance of these is questionable even if done by a DD, *and* you need custom archive keys, so I think it’s best to stick to “more official” ways if these contain all needed packages in unstable (or debootstrap’s patched to handle unreleased). bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312182157360.19...@herc.mirbsd.org
Re: debootstrap and debian-ports
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 debootstrap’able, and has regularily been broken. Good news for m68k though: eglibc, gcc-4.8 and linux are no longer in “unreleased”. In fact: tg@freewrt:~ $ u=/var/lib/apt/lists/ftp.de.debian.org_debian-ports_dists_unreleased_main_binary-m68k_Packages tg@freewrt:~ $ # test idempotency tg@freewrt:~ $ grep-dctrl -r -P . <$u | diff -u - $u | wc 0 0 0 tg@freewrt:~ $ # get me all source packages that have packages in unreleased/m68k tg@freewrt:~ $ grep-dctrl -r -P . -n -s Source:Package <$u | sort -u atari-bootstrap atari-fdisk gcc-4.6 gcj-4.6 glib-networking gnat-4.6 google-gadgets libbluray m68k-vme-tftplilo m68kboot mesa mysql-5.1 vmelilo webkit We can group them by: • architecture-specific packages atari-bootstrap atari-fdisk m68k-vme-tftplilo m68kboot vmelilo • architecture-specific patches, packages going away in sid soon anyway gcc-4.6 gcj-4.6 gnat-4.6 mysql-5.1 (actually already gone) • maintainer refuses integrating our patches libbluray (maybe ping again?) mesa(refusal also upstream) • patches need to be updated against current versions of the packages google-gadgets (waits on webkit/gtk) webkit • “Build without libproxy, for bootstrapping.” glib-networking None of them is, however, strictly needed for debootstrap (although the architecture-specific packages may be needed when d-i’ing a system). I read somewhere that Aurélien regularily creates snapshots of debian-ports – which means that we can install m68k from these, Right Now™. deb http://ftp.debian-ports.org/debian-snapshot/2013-12-12/ unstable main This should work. Maybe Aurélien can “freeze” one of these, if needed? -- Back to debootstrap. Yes, it needs support for multiple versions (already has some, atm) and the unreleased distribution right now. I guess APT’s ordering (from a given package, always use the dpkg-numerically largest version, ignoring all dpkg-numerically smaller versions, period) would work for now, as we don’t have the arch:all/arch:any mix in the minbase, base or buildd set much (except libsemanage-common). Everything else needs a very complicated solver (such as, use an older libsemanage-common that works with the libsemanage1 version in the archive) and is out of scope for the sh-based debootstrap. bye, //mirabilos (short, caught the flu) -- │ untested │ tut natürlich │ was auch sonst ... │ fijn ☺ -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312181709050.19...@herc.mirbsd.org
Re: debian-ports.org getting relatively unstable (hppa)
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 apt-get-update those later on, this leads
>to a "size mismatch" error. I do have the feeling, that this is a
>problem on debian-ports.
I noticed this problem too, when I accidentally built a package
I already had uploaded (and totally forgotten about): basically,
the new *.deb files are accepted but the Packages file still
contains the checksums etc. from the old *.deb file.
Only way to fix this is to reupload the old *.changes file, or
to do a binNMU proper. Or to build a newer version, ofc…
>So, I'm anxious, that if I start the buildd, it will happily build and upload
>packages
>which we already uploaded to debian-ports. If this happens we will get more
>size-mismatch errors.
That’s what you have wanna-build for. Basically, stop doing
manual uploads without wanna-build locking at least six hours
before turning on the first buildd. After that time, when you
want/need to build a package manually, lock it in wanna-build:
either “take” it for building, or mark as N-F-U.
See here for more info on that:
• https://wiki.debian.org/M68k/Porting#binNMU_notes
• http://lists.debian.org/debian-68k/2012/12/msg00124.html
• http://lists.debian.org/debian-68k/2013/10/msg00021.html
If you have packages that buildds should never build, for example
like we had gcc-4.{6,8} for some time, mark them as Not-For-Us;
otherwise, just take them for building.
>deller@leda:~$ wb info hello . hppa
This the same as “wanna-build -A hppa -d unstable --info hello”.
>But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can
>see, that the hello-package is already uploaded at version 2.8-4
Indeed. This is bad, new, another / a different problem, and we
didn’t have this on m68k. (Note that uploads usually take a bit
until they show up on w-b, hence the need for locking.)
>So, if my buildd now uploads the newly created hello package, I'm sure
>we will run again into the size-mismatch problem.
Yes, you will definitely run into that problem when you upload
hello_2.8-4_hppa again.
>My question here on the list would be, if you (other arch-porters) do have an
>idea
>on how I should proceed.
Either…
>Best solution would probably be, if the wanna-build database rescans what's in
>the archive already. Is this possible?
… that (no idea if it’s possible), or make two lists: a list of what
is currently in the archive for hppa, and a list of packages in the
Needs-Build or BD-Uninstallable¹ state. Then, for every package in
the same versions (except +b* sufficēs) in *both* lists, schedule a
binNMU (e.g. to get hello_2.8-4+b1_hppa). Do note whether it already
got a binNMU suffix: e.g. aclock.app_0.2.3-3+b4 would need to be
scheduled for --binNMU=5 to be larger.
You might be able to cheat, e.g. take hello for building, then tell
it that you uploaded it. But I don’t know why w-b doesn’t register
that it’s there in the first place, so a rescan, if possible, should
happen first.
Hm, only 12 packages here:
tg@leda:~$ wanna-build -A hppa -d unstable --list=needs-build | less
But this has more (9043):
tg@leda:~$ wanna-build -A hppa -d unstable --list=bd-uninstallable | less
① You need to include BD-Uninstallable because they will happily
convert to Needs-Build once you upload e.g. perl.
>Or, should I just start the buildd and see what's happening? If we then get
No, get the w-b list consistent first.
According to
http://ftp.debian-ports.org/debian/dists/unstable/main/binary-hppa/Packages.bz2
hello is at version 2.8-4 just fine… hmm. So the apt-ftparchive database
seems to be correct.
This is all quite complicated, so feel free to ask around when we
can help you out again, no need for every arch to go through all
of this by themselves, figure out best practices again, etc.
HTH & HAND,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1312151335210.21...@herc.mirbsd.org
Re: Bug#730258: please add arch-specific BTS tags
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 Wise dixit: >are other ports out there not maintained on d-p.o (like the Interix or Huh, the Interix port is not vaporware? Interesting… bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311240019570.12...@herc.mirbsd.org
Re: Bug#730258: please add arch-specific BTS tags
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.debian.org/status/package.php?p=mksh and http://buildd.debian-ports.org/status/package.php?p=mksh (and ignoring s390 removal) gives us this list: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe ppc64 s390x sh4 sparc sparc64 x32 This keeps hppa, which I’ve seen have some activity recently. >has another; I'd like to reference a canonical location for ports >(perhaps maintained by debian-ports or similar) so I don't have to Even the list on debian-ports is out of date wrt. debian-ports architectures – it misses x32 and arm64, for example. Sorry about that. There seems to be nobody keeping this list up to date so looking at the buildds seems best. Another option is of course to look at what dpkg supports, unearthing things like armeb, arm, avr32, sh3, etc. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311232243030.12...@herc.mirbsd.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
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 massively foreign I didn’t manage to find out anything except that the problem appears to happen before main. >Until we have a clear definition of "actively maintained ports", I would >recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? >[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be >acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311031444380.31...@herc.mirbsd.org
Bug#727642: dose-distcheck: fails on input that works with edos-debcheck and is "correct"
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 version for unscd All Known versions for this package are (libc6,2.17),(locales,2.17),(locales-all,2.17),(nscd,2.17) report: - package: m68k:unscd version: 0.48-2+b1 architecture: m68k essential: false source: unscd (= 0.48-2) status: broken reasons: - conflict: pkg1: package: m68k:libc6 version: 2.17-92 architecture: m68k essential: false source: eglibc (= 2.17-92) unsat-conflict: >>> 64 The file 'x' is attached. edos-debcheck on wheezy handles this just fine: tg@freewrt:~/DP $ edos-debcheck -failures -explain >> $?" Completing conflicts...* 100.0% Conflicts and dependencies... * 100.0% Solving* 100.0% >>> 0 Please cross-reference #727550 in which Ralf Treinen suggested to use this as replacement. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages dose-distcheck depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.17-93 ii libpcre31:8.31-2 ii librpm3 4.11.1-3 ii librpmio3 4.11.1-3 ii zlib1g 1:1.2.8.dfsg-1 dose-distcheck recommends no packages. dose-distcheck suggests no packages. -- no debconf information Package: libc6 Source: eglibc Version: 2.17-92 Architecture: m68k Maintainer: GNU Libc Maintainers Installed-Size: 8557 Suggests: glibc-doc, debconf | debconf-2.0, locales Conflicts: prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch Breaks: locales (<< 2.17), locales-all (<< 2.17), nscd (<< 2.17) Provides: glibc-2.17-1 Filename: dists/sid/main/0_Essential/eglibc/libc6_2.17-92_m68k.deb Size: 2047460 MD5sum: ac5cd6a7fee0621ce747a2baf20c6a7c SHA1: 842393ab17ccf0f8c0f1bca5db873035e0c13ad4 SHA256: f2c09d9af2b2c56236af965ce0d301442c75f70448b53134da60e3de8a90b6ea Section: libs Priority: required Multi-Arch: same Homepage: http://www.eglibc.org Description: Embedded GNU C Library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others. Package: unscd Source: unscd (0.48-2) Version: 0.48-2+b1 Architecture: m68k Maintainer: Don Armstrong Installed-Size: 74 Depends: libc6 (>> 2.17), libc6 (<< 2.18) Conflicts: nscd Replaces: nscd Provides: nscd Filename: dists/sid/main/8_Nice/unscd/unscd_0.48-2+b1_m68k.deb Size: 19016 MD5sum: 4a617bd9b133ac3ab9859c90e75498c8 SHA1: e476ab3e1e09d42b6d035498f58fa80dc1a7b8f7 SHA256: 11dc8c377d6d45b3b759576ae37e31ba6a21b584f26f959f9d5b1f7eb361eeeb Section: admin Priority: extra Homepage: http://busybox.net/~vda/unscd/ Description: Micro Name Service Caching Daemon A daemon which handles passwd, group and host lookups for running programs and caches the results for the next query. You only need this package if you are using slow Name Services like LDAP, NIS or NIS+. . This particular NSCD is a complete rewrite of the GNU glibc nscd which is a single threaded server process which offloads all NSS lookups to worker children; cache hits are handled by the parent, and only cache misses start worker children, making the parent immune to resource leaks, hangs, and crashes in NSS libraries. . It should mostly be a drop-in replacement for existing installs using nscd.
Bug#727550: edos-distcheck: edos-debcheck MUST support :any qualifier ASAP
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 applications Description-md5: 9f24690d2f6e9b70048dc4079a2dfca7 Section: python Priority: optional Filename: pool/main/d/dh-python/dh-python_1.20131021-1_all.deb Size: 51304 MD5sum: 5790257e34d861016fea18b20e3d0294 SHA1: 3a5eaf99f97f7dbf93976ba480ef4a00068131a3 SHA256: e2f8706c54e2852c2f9537f87208059bfee6c66baef2c662801b9cf1094e13ec Package: python3 Source: python3-defaults Version: 3.3.2-17 Installed-Size: 99 Maintainer: Matthias Klose Architecture: i386 Description: interactive high-level object-oriented language (default python3 version) Description-md5: 81733bd73a4c1fc634a99143ddb31ea1 Multi-Arch: allowed Homepage: http://www.python.org/ Tag: devel::interpreter, devel::lang:python, devel::library, implemented-in::c, implemented-in::python, role::devel-lib, role::program, role::shared-lib Section: python Priority: optional Filename: pool/main/p/python3-defaults/python3_3.3.2-17_i386.deb Size: 20618 MD5sum: 7c310b77541682c434c0882f3852ad0f SHA1: 6072efeb030d51e309c6d71699006023368e37be SHA256: 293057a81fbf839516e70a315e6fea0cd75e9c24506ea0e0ec30f2576ad5d360 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages edos-distcheck depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.17-93 ii libgdbm3 1.8.3-12 ii libpcre3 1:8.31-2 ii libpopt0 1.16-7 ii librpm34.11.1-3 ii librpmio3 4.11.1-3 ii perl 5.18.1-4 ii python 2.7.5-5 ii python-debian 0.1.21+nmu2 ii zlib1g 1:1.2.8.dfsg-1 edos-distcheck recommends no packages. edos-distcheck suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131024081712.12852.56726.report...@tglase.lan.tarent.de
Re: Bits from the Release Team (Jessie freeze info)
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 will also be folded). >Jenkins. We can't ask them to rebuild their entire toolchain each night! No OpenJDK either (can probably be fixed, but zero is sloow). Additionally, with only, say, 256 or 768 MiB physmem, running additional software on the buildds is something you do not want, considering how much RAM building some stuff takes (I had to use about 5 GiB of swap to link Webkit, and imagine just how much paging that involves, also in terms of time). Building GCC isn’t exactly resource-saving. (Even running apt/dpkg isn’t due to the sheer size of the archive, though Guillem kindly reduced memory usage in the upcoming dpkg upload.) I think with my “better SCC proposal” we could have a sliding scale for this, but I’d oppose using something OpenJDK-based for that (think of mipsel, too). Especially as simple mksh scripts would take care of the job too (including CGI for web export ;). bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1310231242320.29...@herc.mirbsd.org
Re: Current and upcoming toolchain changes for jessie
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 money. I will, however, forward #711558 to upstream. I can’t do everything, but I don’t think anyone can accuse me of not trying either… >> From me nothing against switching C/C++ to 4.8 for m68k at >> this point, but I’d like to hear at least Wouter’s opinion >> on that, and possibly Mikael since he’s not just doing work >> upstream on gcc but also using it (for ColdFire) heavily. > >same as well, please send a patch. Wouter, Mikael: input on switching C/C++ to 4.8? [ Ada ] >try it and send a patch please. Would be useful to get it compiled first, for which #711558 is currently the blocker AFAICT. But I guess I’ll try eventually. Note to myself: do not “temporarily help out” in any more Debian projects, you’ll never leave them… bye, //mirabilos, sponsoring for a week of Linuxhotel would be nice… (I’m seriously short of hacking time, in general, recently, and could use some switching of paper hangings for a while) -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (259 (278) bugs: 0 RC, 182 (196) I&N, 77 (82) M&W, 0 (0) F&P) ‣ src:dash (86 (102) bugs: 3 RC, 41 (46) I&N, 42 (53) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306141907290.27...@herc.mirbsd.org
Re: Current and upcoming toolchain changes for jessie
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 build queue. True; that’s new, but it’ll be done eventually, no hurries there ☺ bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (259 (278) bugs: 0 RC, 182 (196) I&N, 77 (82) M&W, 0 (0) F&P) ‣ src:dash (86 (102) bugs: 3 RC, 41 (46) I&N, 42 (53) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306132021420.22...@herc.mirbsd.org
Re: Current and upcoming toolchain changes for jessie
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++ to 4.8 for m68k at this point, but I’d like to hear at least Wouter’s opinion on that, and possibly Mikael since he’s not just doing work upstream on gcc but also using it (for ColdFire) heavily. For Ada, I’d like to see a successful build of gnat-4.8 (from src:gcc-4.8, if I understand the recent changes right) first; gnat-4.6 mostly works at the moment, but I’m not sure about the upstream situation wrt. patches from Mikael. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306131944240.22...@herc.mirbsd.org
Re: changing the java default to java7, and dropping java support for some architectures
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 architectures to drop java support >would be Yeah, sorry, I really should contact the Zero developers about why it doesn’t work on m68k. On the other hand, judging from the talk at FOSDEM, their focus seems to be on Shark these days, and Zero isn’t worked much on upstream either… but “us porters” should definitely get at least Zero working. (No LLVM for m68k in sight. There’s a project, but everything interesting is stubbed out. I don’t do C++.) bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305061920550.7...@herc.mirbsd.org
Re: [klibc] klibc issues on armhf (not Debian/armel)
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 at its end (does this saying translate into English?), I’ve got no idea how to track this down. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205271455421.24...@herc.mirbsd.org
Re: [klibc] klibc issues on armhf (not Debian/armel)
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. >not sure that klibc picks those up? I built klibc with those very same flags on harris, yes. (And added CONFIG_KLIBC_THUMB=y just to see whether that helps.) The problem is that “random” pointers suddenly contain NULL, and that some code is apparently not run despite being in between oder two codes that are run. Also, setjmp() seems to exhibit issues. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his depply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205271431420.24...@herc.mirbsd.org
klibc issues on armhf (not Debian/armel)
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), but not 100% sure I’ll find it, so more eyes on klibc would not be unwelcome ;-) maks, does klibc on armel build thumb or not, and does it differ from armhf in more than optimisation flags? (Does klcc use the same flags as klibc itself was built with?) Thanks, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205251901480.20...@herc.mirbsd.org
Re: GCC 4.7 is now the default for x86 architectures
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, last time I looked gcj-4.7 didn’t but it is currently building again (so let’s see whether it does this time); gcc-4.6 and gnat-4.6 are getting development and bugfixes (I’ve queued up some patches, but am not entirely ready with all of them, plus some for binutils and gdb), and I’ve asked for help re. the gcj-4.4/gcj-4.6 recent problems. But nothing has tested gcj-4.7, and I fear of new and old bugs… so I’d rather not switch default compiler to it anytime soon. As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_ runtime) told me that it dropped support for an old method of doing things while not fulfilling the promise to get the new method of doing it (don’t exactly remember what it was, /msg js on freenode for details) fixed, with the effect that gobjc-4.7 is virtually useless/broken. This is hearsay, but ask him for details, and check them against reality. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205071730550.28...@herc.mirbsd.org
Re: [armhf alpha hppa] manual experimental build request: dietlibc, then mksh
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 cowbuilder, not just dpkg-buildpackage.) > mksh (40.2-3exp1) experimental; urgency=low Skip that on ARM until a fixed GCC is uploaded. >Note that mksh (40.2-3exp1) dep-waits on dietlibc (>= 0.33~cvs2008-1) Thanks, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.101853200.31...@herc.mirbsd.org
Re: [armhf alpha hppa] manual experimental build request: dietlibc, then mksh
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? ;-) > >Looks like the bug has been fixed upstream: >http://gcc.gnu.org/viewcvs?view=revision&revision=178636 > >So, it seems it's a matter of waiting for a backport of the fix or >something like that. Hi Matthias, can you please include that fix and upload a new gcc? Thanks a lot, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.091622200.3...@herc.mirbsd.org
Re: [armhf alpha hppa] manual experimental build request: dietlibc, then mksh
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 bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.091155330.24...@herc.mirbsd.org
[armhf alpha hppa] manual experimental build request: dietlibc, then mksh
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 for this is: I’ve uploaded a dietlibc source package that _hopefully_ fixes the armhf and alpha problems, and which should give us insight into the hppa problem (if it persists, we’ll apply a workaround and ask for another build). I’d like to check that, then upload that fixed dietlibc package to unstable. mksh currently is “the best” dietlibc testsuite I know of (and compiler testsuite ☺) and runs the tests on (native) builds. Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.091032090.30...@herc.mirbsd.org
Re: GCC-4.5 as the default for (at least some) architectures
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 keeping gcc-4.4 for a while (kernel?) and switching to gcc-4.6 directly for m68k. I know I’ll probably have to invest some work into the latter, but considering the kernel problem is almost solved, chances are good. (I do want to bring out a new base emulator image first, though, but then…) bye, //mirabilos -- 13:47⎜ if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org
