H. Mijail's Blog

Typically, when I start seeing a film, I only have enough time to quickly get some subtitles, try to make them more-or-less work with the film at hand and ... that's it. So, lots of repetitive, rushed fixes but no long-term solutions. But this time I got sick of it and tried to get to understand the problem. Which is: Polish subtitles don't work with mplayer, or at least not with the mplayer built with MacPorts' mplayer-devel port, which uses mplayer's SVN HEAD. The option -subcp cp1250 does select the codepage (cp1250 is variously called Windows Latin 2 or Windows Central European encoding, which seems to be the typical encoding used by polish subtitles on the net) The option -subcp enca should auto-detect the encoding, but the port disables enca at configure time, and provides no way to enable it. I'll try to send a patch for that. In the meantime, enca -L pl -i file by itself works nicely (enca is provided by a port). For difficult cases when enca fails...

Tcpflow 1.0.2, as built with MacPorts, doesn't work when net expressions are used. But 1.0.6 does work. I already submitted a new portfile so it should be available soon.

socat (1.7.2.0 as of this writing) doesn't compile with the clang, the standard compiler in Mac OS X 10.7 Lion (10.7.2 as of this writing). It does compile if instead of clang one uses for example llvm-gcc-4.2.2. The developer reports that this is a bug; only gcc is supported in socat, but there are compatibility fallbacks for other compilers. Only, the fallback was missing on the file that fails to compile, xioexit.c. The fix is easy: @@ -5,6 +5,7 @@ /* this file contains the source for the extended exit function */ #include "xiosysincludes.h" +#include "compat.h" #include "xio.h" (if someone is trying to build something like socat, I guess he doesn't need help about patchfiles) This problem was also present in MacPorts' port for socat. I have already reported it and provided a new working portfile, so I guess it won't be long until it is published.

~/MacPorts/ports$ sudo port install socat --->  Computing dependencies for socat could not read "/Users/mija/MacPorts/ports/sysutils/socat/Portfile": permission denied I was having strange problems to use a locally edited portfile. Turns out the permissions were wrong in a directory in the path; each of the directories should have at least o+rx permissions, and strangely my $HOME had none of those (strange because other users in my computer had o+rx, admins or not). Note that MacPorts lately (from 2.0?) has started to use the user nobody at some points of its workings, and root at others; in this case the user nobody was the one unable to reach the Portfile. A way to check what this user sees is " sudo -u nobody ls -leda@ /Users/mija/blabla ". A workaround is setting macportsuser in /opt/local/etc/macports/macports.conf to root, but that's not a good idea. MacPorts is doing the the sensible thing, de-escalating privileges when they are not needed; th...

(express post, too much time spent on this but too much work spent to let it slip without benefitting someone else) 1.1.6 is not released, had to be hg-cloned. In fact, the repository looks like the 1.1.6 tag was at some moment added but then deleted?? That branch also has the latest video stabilization, no idea yet if it is also in 1.2 Can be compiled. Get the hg repository via hg itself, not one of the zip/bz/etc packaged from the website since the compilation scripts expect to find the .hg files. Read the README and INSTALL, you'll need to create the configure yourself (easy, just read) I am using MacPorts, and even installed the included Transcode 1.1.5, so all the requirements are already installed. Most of the expected work was about configuring tne non-macports transcode to use the /opt dirtree. (Incidentally: 1.1.5 has horribly mismatched documentation, I have had to resort to using strings and source code to understand what some of the utils were supposed to ...

PyQt4 (MacPorts' py25-pyqt4) was causing a Bus Error. Some previous problems with the Python 2.5 installed by MacPorts made me think it could be some dependency with the native library called by the Python module; that is what I think that was also happening with py25-hashlib, which caused an error about being unable to find _md5 or some such, and which got fixed by uninstalling MacPorts' openssl 0.9.8g and installing 0.9.8h (and reinstalling py25-hashlib afterwards). (and I say " think " because maybe that problem was unrelated to openssl, and in fact could be related to python_select , which I maybe had or had not run. Read on for more on that. Anyway, there was also some report online of problems between Pythons' hashlib and openssl because of the exact version used, and mentioned Python being a bit fragile in that respect — although it didn't say if that was because of a not-too-robust build/installation process, or because of Python's design.) ...