Today’s pcc from anoncvs bootstraps successfully and builds mksh just fine, and is amazingly fast (almost en par with Microsoft’s compiler). Wow, they fixed all the things I ranted about in my earlier postings. Congratulations, pcc team.
Now tcc and TenDRA/Ten15 (schizo) are next (mainstream compilers failing). And LLVM/clang and ACK deserve testing.
I wish ranting would help with my internet connection… gotta fight with the ISP/Telco now.
I already ranted about pcc… well, I got a reply to my first mail to the pcc list (where the second one cleared up the five things mentioned in the previous posting), a sort of still friendly one-liner, to which I replied with that he should probably read my other mail, to which I only got an unfriendly comment that “you are wrong”. Hah! (Well, I got my “pcc -E” fixed.)
I guess I just cannot recommend to use pcc, and will have to maintain my own set of patches. Trying to get them upstream shipwrecks on a barrier of incompetence, regarding not only autotools but also how a compiler (cc(1) standard interface) must work: at first, on -O (or -O*), pcc did simply an Oflag++; which I mentioned as wrong (adding a fix)… but look for yourself. Oh, and they reply using weird – OpenBSD (latin1) or Windows (cp1252) – encodings on mails properly sent using Unicode (UTF-8), as is the default in sane operating systems like MirOS and Plan 9. Incompetence whereever you look. This matches the interesting UCB hack in mv(1) I recently found… or OpenBSD’s inability to port GNU tools.
Also, I suppose my ISP/Telco is going to get some angered tg@ tomorrow. The NTP Pool scores show that I’m suffering from a lot of network hiccups. This LCP fluctuation kind of sucks, as does the current transfer rate. Just the latency is still surplus, 11.2ms to heise.de (suckers as well, but for totally different reasons) and 18.3ms to google.com (also suckers, for a couple of yet another reasons I think I already elaborated).
I probably could compile mksh on pcc again… if pcc would compile itself. Hey, this one is about the contrary of OpenBSD or lynx, where development versions are stable… pcc should warn before cvs upping.
Every time I try to build mksh with pcc, either it’s totally b0rked or I have to fix it. Today: ragge doesn’t understand autotools. (He added a test to configure.ac which ① gives a syntax error when failing, ② fails when compiling pcc using pcc as the compiler, ③ doesn’t show up if /lib/cpp exists (on GNU/Linux, I suppose), ④ produces a broken cpp(1) executable if it fails, ⑤ doesn’t even test for the thing it is supposed to check.)
Oh, and the charsets of the mails are b0rken. (WTF windows-1252 when I send UTF-8?) See all the ugly details here (XXX insert link).
Back home… there just ain’t such place as [::1]… (that’s localhost for all of you who don’t use BSD). Swinging on the bike and going to the ice dealer, the best of them all. It was kind of nice in Switzerland and it’ll be a hard decision for me whether I’m going to move there or not. But after arriving at home, past the bike tour, I fell into sleep pretty soon. Travelling may be interesting, but it sure is tiring.
Too bad I couldn’t find the two geocaches I looked for on the way back.
I hacked some mksh on the train, until I had no power left in the batteries… the laptop literally just went off all suddenly… and continued that until now. We have some quite interesting new features in now, only sad point is that we still can’t hexdump NUL.
I should definitively get my new server (tear) running now, for which the only dependency left ought to be the updated vnd(4) crypto stuff. This will take a while, as I’ll design a new on-disc format as well for improved security (think of keys, IVs, and so on). After that’s done I’ll give y’all a snapshot of MirOS-current, and update a lot of ports.
Maybe I should work on bringing a regular sparc boot floppy into the tree as well – last time, I had to hand-craft one. But it will be lacking.
There’s so much interesting stuff to do. Working on the Zaurus, ALIX, my SPARcstations (still no big monitor yet, so I couldn’t test Miod’s patch to make tvtwo(4/sparc) work yet), more FreeWRT devices… but I can’t neglect my dayjobs either. And I ought to learn to read and fix Perl *sigh*
This sucks: I have network (internet) outages since last night. Sometimes, ppp(8) + pppoe(8) still work when pppoe(4) doesn’t, but most of these times, both are unusable. The rest of the time, I sometimes have huge lags. My ISP (which unfortunately is a telco, but they aren’t completely clueless either) wanted to upgrade me from a 4 Mbit/s connection to a 6 Mbit/s connection as the old product doesn’t even exist any more (and I’ll save 10 €/month now), and the cable length (230m) isn’t an issue either. Testing today (as per the salesman I should have it May 1st, per the acknowledgement mail April 15th) I’ve got about 6 Mbit/s down, but my upstream speed is even reduced! WTF?
Argh! Later on this night, my network connection is so flakey…
This time I did find a geocache far away from home…
… in contrast to when I was in Bruxelles, as Benny and gecko2 didn’t seem to want to have time for that (or walk at all, they coerced me into the tram). This time, I went cacheing with Tonnerre, and he kind of lined it.
Time to push opencaching in Switzerland. He said he might even drop some caches (although – jokingly I hope/suppose – his first idea was „Finding Sandro“, where the cache is a person… or his home appartement). Likewise, I’ll push OC (and, a little, TC) whereever I’m going to live or lived.
While here, special greetings to the TGIF@BS meeting which I won’t attend, as I’ll take an earlier train back home tomorrow. It was nice here, much more so than in, for instance, Berlin.
Perl is evil. But knowing the basics of other programming languages helps. I guess I’ll invest some time into learning perl better, so that I can get rid of it (in MirPorts, for example), and better understand what others try to write in it (so it can be converted to mksh if possible, or at least fixed or optimised).
People can be quite annoying at times (mostly in Jabber, but also via eMail or IRC). Hey, if I just don’t reply my current location per eMail, sending another one asking specifically for it again isn’t going to improve my mood. Neither is constantly annoying me with enquiries about whether I’m really gonna move („zügeln“) here or not, after I had already stated I’ll think over it next weekend (or so), since I have a few reasons pro et contra, some of which are orthogonal to what I see here. I concentrate on getting a feel right now. Oh, and texting me one messager after another in Jabber (or, worse, by SMS to my Natel) even if I don’t reply (which, on the other hand, does not imply I’m willing to conversate either!) just gets on my nerves. And: go fucking RTFM, and don’t fucking bother me with „the XXXXU2B controller doesn’t exist, because the vendor website only lists the XXXXU2W“ – if you know any vendor websites you should long know better than to trust them.
For what it’s worth: for building MirEwe, you need very current MirMake (at least 20080411), g++, GTK+1.2, GTK+2, libjpeg, zlib, and their development headers. It should work on GNU/Linux and the BSDs for now. No platform other than i386 has been tested yet, but I’ll take on the Zaurus running OpenBSD, I guess, as I finally got the uplcom(4) working. Ah, and to rebuild the class libraries you need ecj and paxmirabilis/MirCpio – I did the ecj part on Debian and the rest on MirBSD.
XTaran mentioned that there is a Secunia advisory for mksh: SA29803. Wow. This would then be my first one. But people really cannot read: the advisory states it appies to “Secunia Product #18328: MirBSD Korn Shell 3.x” – WTF? I mean, version numbering surely is difficult these days, with Linux and related software often having four or more decimal points(!) in them… but I reported it to them using their web site form.
I don’t know why Secunia made this advisory, but I suppose the Fedora person has his hands in there, as he told me yesterday that he needs an advisory for marking the update as security fix in their package system. I told him that this is not a lack of wanting to document, or even lack of communication (skills), but that I merely don’t know how this kind of issues is usually handled “out there”. I haven’t dealt with GNU/Linux any more since I started using OpenBSD back then in 2.9 times, and then, this procedere wasn’t widely used.
Ah, speaking of OpenBSD. They are sometimes not even at fault when a bug report is mis-communicated, even if some people don’t believe it. And they don’t do the major/minor game either. They just still have the decimal dot for hysteric raisins.
Actual user feedback matters. My fork (MirEwe, just to annoy Jonathan) of the Ewe VM now has a fix, or rather workaround: when opening serial devices, “/dev/” was prepended to the device name. Now if users enter “/dev/ttyUSB0” (leenocks) things don’t work – but this is hard to debug. MirEwe now warns and does the right thing. The warning is in there for portability ☺
Ah, and: I could finally log my first (locationless, though) TerraCaches. That makes me an active user of all known platforms. Even if it cost me an entire night of re-reading a book I knew from a looong time ago. But actual caches will follow, and I’m even already planning to plant some myself.
Basel is getting nearer. I’m still not too happy with the option to move away from here. We’ll see – at least I’m going to take a big chance when I see one, and peek into how it is over there. Even if Benny is on Malle.
How can a bug like this be unnoticed for so long, while the two source code lines in question were specifically touched and diffs reviewed by big names such as deraadt?
Of course it’s me who has to fix longstanding bugs from 386BSD, VIA C3 AES data corruption bugs in the OpenBSD kernel, LP64 bugs in OpenSSL, etc.
As you can read, quite a few new versions of our portable software has been released. Well, sort-of-portable, but for nroff I plan on improving, and MirMake 2 will be a lot better too, kinda like mksh.
Even Jonathan got hooked now. We found another (his first) two today.
As we’re sort of a big family, you’ll occasionally find German-language postings here. Don’t wonder. We have people who especially read that.
Ah, and while we’re at stats bragging:
These were made on gecko2’s Intel Mac (Darwin), my laptop (MirBSD), and a few even on hephaistos (GNU/Linux). MidnightBSD needs to use brandelf, thus execution of Linux/i386-ELF binaries fails or, after branding, checksum verification (which BOINC does) fails. Sucks to be FreeBSD derived.
I’ll be in Switzerland (Cōnfœderatio Helvetica) next week, while Benny happens to be on vacation on Mallorca (hopefully not near the war zone called Ballermann). Development may slow down a little due to that (no more 100+ CVS spa^H^H^Hmails per day, yay!) but will not stall.
Ad auditorēs qui nōn possunt legere linguam germanicam: Salvete amici Cōnfœderationis Helveticæ!
Ich bin übrigens Mitte der Woche in Basel zu Besuch, Benny ist leider zur Zeit auf Mallorca, Urlaub machen. (Hoffentlich fernab vom Kampfgebiet, äh, Ballermann und so.)
I haven’t written here for a while, but I just want to get one thing said. I might have done what Sun feared first thing after I got a Java™ VM (even if it’s only single-threaded Ewe for embedded systems) running stably on MirOS… it now has a native method arc4random_pushb(3)… yeah!
Entropy is determining a lot of my life these days anyway. For example, accidentally sleeping too few, too much or at weird times, being phoned by random people, talking with Vutral about further possible improvements in our RNGs, being asked by CAcert.org if we are suitable OS for their high-security boxen (almost, but we’ll fix the missing parts, and some they’ve got to do themselves as no off-the-shelf OS does), and reporting in huge masses of entropy to CAcert.at Research Lab – some 128 MiB samples with Firesomething “Bon Echo”, as Opera ISE’d out and Lynx just first ate up all CPU then none at all any more without monitorable activity…
Ah, and BOINC is running stable on MirBSD. MidnightBSD has some issues, mainly due to the fucked-up FreeBSD kernel and brandelf.
When Mozilla Firefox(TM) aka www/firesomething version 126.96.36.199 came out over a year ago, I tried porting it (of course). However, not only did the build not finish, it filled the entire filesystem before failing. At the time, I was updating from something like 188.8.131.52 so I did not know which version exactly caused the problem. Thus, I made incremental updates up to 184.108.40.206, where I seemingly lost interest. Now, with a faster build machine, I continued the updates, discovering that 220.127.116.11 is really the version that fails.
A diff between firefox-18.104.22.168-source.tar.bz2 and firefox-22.214.171.124-source.tar.bz2 is 10 MiB. Most of that is in CVS directories, which are included in their fucking releases, believe it or not. If you leave out those changes, the diff is still 5 MiB and 155000 lines, of which 90% are in security/. Mind you, the whole source tarball, from calling the directory mozilla instead of adding a version number to including CVS directories to using several different build systems, leaving unused configure scripts in the tree, etc., positively REEKS of a flagrant disrespect for those that build from source. All this seems to be meant to encourage you to use official Mozilla builds—which is fine if you happen to be on one of the few supported platforms: Windows, Mac OS X, and Linux i386. We are not.
Anyway: in their infinite wisdom, the Firefox developers chose to upgrade the included NSS libraries (Netscape Security) from 3.10.x to 3.11.4 in a minor security update. This version sports extensive internal restructurations—another nice way of saying "fuck you, porters". Thank you, Mozilla project. Of course, the NSS update is not explicitly mentioned in the release notes.
This tech note says: "The low-level freebl cryptographic code has been separated from softoken on all platforms. Even on platforms for which there is only one implementation of freebl, there is now a separate freebl shared library. The freebl library implements a private interface internal to NSS." This new library is the core of the problem. After the NSS libraries are built, they are cryptographically signed by a program called shlibsign which, in turn, dumps core, generating a 3 GiB core dump in my case!
I had suspected a problem related to our security features, especially W^X. The page about Building on Fedora Core 5 says: "For those with SELinux in enforcing mode, you are likely to run into problems both with the shlibsign during the build process and with the running the final build related to SELinux denying execmod permission ..." However, with some difficulty, I managed to build a debug version of everything for analyis with gdb. During the start of shlibsign, one of the init procedures loads the native freebl (?) module, which promptly loads itself. On and on, until memory exhaustion.
This comment in security/nss/lib/freebl/Makefile provided a clue to the solution:
# The blapi functions are defined not only in the freebl shared # libraries but also in the shared libraries linked with loader.c # (libsoftokn3.so and libssl3.so). We need to use GNU ld's # -Bsymbolic option or the equivalent option for other linkers # to bind the blapi function references in FREEBLVector vector # (ldvector.c) to the blapi functions defined in the freebl # shared libraries. ifeq (,$(filter-out BSD_OS FreeBSD Linux NetBSD, $(OS_TARGET))) MKSHLIB += -Wl,-Bsymbolic endif
Adding MirBSD to the OS list fixes the build. And it works!
Now, firefox 1.5 is old and unsupported. So why was this update important? It makes further updates possible. The same bug was holding up my long-finished firesomething-2.0 port. I already have a package for firefox 126.96.36.199 but the port needs just a little more work. I am also confident I will be able to provide a working port for firesomething 3 when released.
Wow, my first posting in this new weblog. My laptop, a new MacBook Pro, spent about 10 days over easter in order to really do a MirPorts bulk build. 1503 binary packages for MirOS #10 have been uploaded to the mirrors. This has also been an occasion to review some largely untouched parts of the tree. Most of the problems seen are related to missing distfiles, changed download URLs, etc. Some packages did not build during th bulk build but when run non-recursively, they worked.
Some bugs in the resulting packages remain: You must manually install the expat package for most of the stuff to work. gtk+ insists on writing to /var/db, which makes it unsuitable for AS_USER builds. firesomething only when works as firefox. Still, this gives you a wide variety of pre-built packages for the new release. Enjoy!