Skip to content

Yum & CTRL-C

I can't believe yum still has a problem with CTRL-C. When aborting an operation in F13 it still prints a horrible-looking python-backtrace and then just hangs. It seems to switch to the next mirror rather than "interrupting" the operation as one would expect. Well, not everybody apparently. Oh well, maybe something futuristic like CTRL-C will be implemented in F23 or so :-)

One thing that is cool about yum is presto:
$ sudo yum upgrade
Transaction Summary
Install       0 Package(s)
Upgrade  99 Package(s)

Total download size: 198 M
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Download delta size: 11 M
There's debdelta for dpkg, but I haven't seen it properly integrated yet.

Bigger, better, faster

This blog is kindly hosted by some bigger German ISP, but due to, well, let's say certain circumstances it doesn't provide a MySQL database. I know, s9y can use SQLlite, but we're too cool for this, right? So, this MySQL database has always been hosted by some lonely machine an someone's closet, serving this blog's queries over in incredibly fast (hah!) ADSL uplink.

But not anymore! I'm happy to announce that the database has been moved to a box with 100Mbps uplink, happily awaiting your visits - yay!

Thanks, Malte!

tr: Illegal byte sequence

$ cat /tmp/foo
$ tr -d \r < /tmp/foo 
tr: Illegal byte sequence
Whoops? Let's take a closer look:
$ od -x /tmp/foo 
0000000      73ff    0a0d
So, it's some unicode character (0xff), a small "s" (0x74), then a CR (0x0d, which I'm trying to remove) and a newline (0x0a) at the end. Turns out it's how MacOS 10.6 handles unicode characters. Specifying a different locale seems to help:
$ LC_CTYPE=C tr -d \r < /tmp/foo 

Changing the default column list in Thunderbird

Appaerently Thunderbird 3 now allows the column headings to be set on a per-folder basis. While this is might be a neat feature, it is also quite a pain for all the others wanting one default column list for all their folders. Luckily, there's a workaround to accomplish this:

  • Set layout for the uppermost folder ("INBOX")
  • Quit Thunderbird
  • Delete all but the INBOX.msf .msf files from your profile directory:
    find ~/Library/Thunderbird/Profiles/*/ImapMail -name "*.msf" \
             -a ! -name "INBOX.msf" -exec rm -v '{}' + 
  • Start Thunderbird again, now the default layout should be propagated to all the subfolders.

equivs FTW!

OK, so I really don't get the point why mountall (and cryptsetup) depends on plymouth now. Until this will be resolved (hah!) and with me being stubborn enough not to install plymouth again (after forcefully removing it), I'm left with:
# apt-get install foo
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
  cryptsetup: Depends: plymouth but it is not going to be installed
  mountall: Depends: plymouth but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
Not a nice thing to be stuck with. But equivs is here to help:
$ equivs-control plymouth-dummy
$ vi plymouth-dummy

$ grep -v ^\# plymouth-dummy
Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: plymouth-dummy
Provides: plymouth
Description: plymouth-dummy, see LP# 556372

$ equivs-build plymouth-dummy 
$ ls -lgo plymouth-dummy*
-rw-r----- 1  826 2010-04-08 16:45 plymouth-dummy
-rw-r--r-- 1 2040 2010-04-08 16:47 plymouth-dummy_1.0_all.deb
Then I was able to install plymouth-dummy_1.0_all.deb (via dpkg -i) onto the system in question. Mind you, the equivs thing was done on a Debian/powerpc system, as I couldn't even "apt-get install equivs" on this b0rken Ubuntu/amd64 box. Talk about portability! :-)

Internal Error, Could not perform immediate configuration (2) on mountall

# lsb_release -a 
Distributor ID: Ubuntu
Description:    Ubuntu karmic
Release:        9.10
Codename:    karmic

# apt-get update && apt-get -V dist-upgrade
Need to get 0B/197MB of archives.
After this operation, 239MB of additional disk space will be used.
Do you want to continue [Y/n]? 
E: Internal Error, Could not perform immediate configuration (2) on mountall
Huh? What happened here? I mean, I still had this mountall bug around, so it wouldn't surprise me if apt-get runs some hooks on mountall to make sure we're actually up & running. Let's "fix" mount for now:
# mountall 
swapon: /dev/mapper/swap: swapon failed: Device or resource busy
mountall: swapon /dev/mapper/swap [15521] terminated with status 255
mountall: Problem activating swap: /dev/mapper/swap

# grep swap /etc/fstab 
## /dev/mapper/swap swap       swap    pri=1        0       0

# mountall 
Now mountall returns properly, but apt-get dist-upgrade would still present the same error. Manually installing the package in question helped:
# dpkg --force-all -i /var/cache/apt/archives/mountall_2.10_amd64.deb
# apt-get -f install
# apt-get -V dist-upgrade

one step forward, two steps back

It finally happened: Comcast has signed me up for their Data Usage Meter, as I don't belong to the "vast majority" of their customers:
Your Comcast High-Speed Internet service has a monthly data usage allowance
of 250 gigabytes (GB). If you are wondering whether you are at risk of exceeding
this 250GB threshold, you should know that the vast majority - around 99% - of
Comcast customers use significantly less than 250GB per month.
huh? I thought volume-based contracts are a thing of the past. It's all about flat-rates now, no? It's 2010 now and they're still maintaining this limitation. I've even throttled my RelayBandwidthRate to 90KB/s but I'm still exceeding their 250GB/month:

So, what's next? Their FAQ states:
If you exceed more than 250 GB and is one of the heaviest data users who consume
the most data on our high-speed Internet service, you may receive a call from the
Customer Security Assurance ("CSA") team to notify you of excessive use. At that
time, we will tell you exactly how much data per month you had used. When we call
you, we try to help you identify the source of excessive use and ask you to moderate
your usage, which the vast majority of our customers do voluntarily. If you are
contacted by the CSA team again for excessive use within six months of the first
contact your service will be subject to termination for one year. We know from
experience that most customers curb their usage after our first call. If your
account is terminated, after the one year period expires you may resume service
by subscribing to a service plan appropriate to you needs.
(yes, the spelling errors are really in the FAQ). I like the last senctence the best - as if anyone would subscribe to the ISP again who kicked them out before :-)

Well, let's see when that happens and hopefully I'm already moving out when they're about to terminate my contract - that way I'd save postage sending my cancellation letter :-)

Oh, the reason why they've set up this limit is customer feedback, of course.

Update: I've reduced AccountingMax again, now we're down to 3GB/day, which will be reached after ~15 hours, the remaining hours my Tor daemon will live in hibernation, oh well. I've updated the graph above. It's May 13th now and I just passed 100 GB. For the record, Comcast did not call yet....maybe they're busy sniffing exit nodes, hm?

oh, the pain....

I'm trying to install Skype (don't ask) onto this iMac (Intel) running Ubuntu 10.04 and I'm already super annoyed. Generally I don't like 3rd party software installed as a .deb package, so let's go for the dynamically linked version, shall we? Only 19MB to download, I'm sure Ubuntu has already installed all the necessary libraries.
$ ./skype: error while loading shared libraries: 
   cannot open shared object file: No such file or directory
$ ldd ./skype | grep not => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found => not found
Wow. that's a lot of "not found" there. But it was late and I didn't think of it much, let's just get the statically linked version instead. With 26MB a bit bigger, that must be because they stuffed all the needed libraries into the tarball, right? No, they did not. There were even *more* libraries not found. Huh? But again, I did not want to spend time debugging this and I went to to get the Ubuntu package (8.10, 64bit). Yes, it's quite old (I'm sure they've backported all their security fixes, hm? :-)) but 64bit, that's my address. Alas, it still would not work - but this time the install process gave it away:
# dpkg -i /root/pkg/skype-ubuntu-intrepid_2.1.0.81-1_amd64.deb 
Selecting previously deselected package skype.
(Reading database ... 143081 files and directories currently installed.)
Unpacking skype (from .../skype-ubuntu-intrepid_2.1.0.81-1_amd64.deb) ...
dpkg: dependency problems prevent configuration of skype:
 skype depends on lib32stdc++6 (>= 4.1.1-21); however:
  Package lib32stdc++6 is not installed.
 skype depends on lib32asound2 (>> 1.0.14); however:
  Package lib32asound2 is not installed.
 skype depends on ia32-libs (>= 1.6); however:
  Package ia32-libs is not installed.
 skype depends on lib32gcc1 (>= 1:4.1.1-21+ia32.libs.1.19); however:
  Package lib32gcc1 is not installed.
dpkg: error processing skype (--install):
 dependency problems - leaving unconfigured
wtf? Why do they label it "64bit" when it clearly isn't? Now I have to clutter my system with these 32bit emulation libraries again. Sigh.