Posts Tagged ‘debian’

Deprecation of $(ARCH)-geomirror.debian.net

2013.04.30 21:04 by Leo Antunes - 8 Comments

[UPDATE 2013-05-18: with Raphael Geissert’s help, all users should be now – or as soon as DNS entries propagate – be using http.debian.net without need for any change]

After the announcement of http.debian.net some months back I imagined the few people using my older $(ARCH)-geomirror.debian.net DNS redirector would relatively quickly jump ship to the newer solution, it being superior in basically every aspect. However it seems I had highly underrated the usage of my little hack. According to the server logs there still are a sensible number of genuine-looking queries being made (around 600 unique IPs in the last 3 days), and even if a sizable fraction of them are being generated by bots, this still leaves a pretty big number of potential users out there.

So I guess it’s only common courtesy to let these potential users know in a slightly more public place that I plan on pulling the plug till the end of the year. If you’re one of the people making use of the service, please migrate to http.debian.net.

Note however that this has nothing to do with cdn.debian.net, besides being based on a similar idea.

Importing an Outlook PST into IMAP

2011.06.19 17:16 by Leo Antunes - 9 Comments

Well, every once in a while we’re forced to do something that isn’t particularly interesting or pleasant. Last week it happened again: I had to import a few pretty big PSTs (most 2Gig, one 10Gig, with about 100.000 emails) into our dovecot IMAP.

Doing this with Outlook itself was out of the question: it took way too long, even on the local network (many hours for a 1G file) and was prone to hanging and crashes, which were obviously a pain to debug and start over.
Thunderbird was unfortunately not much better, since – at least in our tests – it didn’t import the read status of the emails (they were all marked as unread) and also wasn’t particularly good at handling folders with strange names, containing “.”, “/” or some more obscure characters. We had used it before for smaller files, where manually dealing with the problems was acceptable, but this time it required something a bit more elaborate, if we were to keep our sanity.

Enter libpst. It includes the handy readpst utility which dumps all emails in usable formats in a directory tree, one directory per folder. Unfortunately the Debian version is somewhat outdated and doesn’t support the newer Outlook formats, so I did some packaging and even a little bit of patching. It seems Thunderbird also uses this library, which would explain why it didn’t handle the Read-Status (haven’t confirmed this though; just read it somewhere).

The last step was this not-so-little script, which uses the dumped directories from readpst and imports them in IMAP. It would have probably been a bit more elegant to use libpst directly, but I unfortunately didn’t have the time to mess around with that. I did have to mess around a lot with encodings though, ergo the unholy chaos with unicode()s and str.encode()s thrown around like rice at a wedding (I could never really wrap my head around charset problems; the subject boggles my mind to this very day).

code after the jump
Read the rest of this entry »

Yeah, about that…

2010.02.03 18:23 by Leo Antunes - 2 Comments

I was trying not to complain about it, but now that the number of people asking me about it is getting bigger, my frustration got the best of me.

I'm NOT going to FOSDEM 2010

So unfortunately I won’t see you all there.

Re: Making pbuilder just that little bit faster

2009.12.29 23:45 by Leo Antunes - 1 Comment

Absolutely, but there are at least two workarounds:

  1. Adding
    BINDMOUNTS="/var/cache/apt/archives"
    APTCACHE=""

    to your .pbuilderrc, in case you don’t need any special separation of local and pbuilder caches (that’s my case).

  2. Using apt-proxy or the like, which has its overhead, but also its other advantages.

None of them seem all that bad to me, considering the sensible speed improvements to pbuilder, but the ultimate decision probably depends on the amount of disk-access the packages in question need.

Notes on the Google Chrome™ Debian package

2009.12.08 22:23 by Leo Antunes - 9 Comments

Just some quick superficial observations on the Debian/Ubuntu package distributed by Google:

  • Most files are installed in /opt/google/.
  • It attempts to patch /usr/share/gnome-control-center/gnome-default-applications.xml on postinst (maybe legacy compatibility? Someone with more gnome-fu than me care to explain?).
  • The postinst also automatically adds a souce for updates to /etc/apt/sources.list.d and an archive key (this is IMHO the worst part)
  • It includes a daily cronjob that – at least at first glance – tries to do the same things the postinst did (new apt source, archive key, etc) and some further archive configuration. The cron script is called at the end of postinst.
  • A casual look at objdump suggests it’s statically linked to libv8
  • On a slightly more positive note, it at least seems to successfully undo most of the changes once removed, with the exception of the added archive key and the above mentioned patch to gnome’s default apps list (that is: if there’s any situation it actually gets applied).

I understand it might be too much hassle doing it the right way (from the corporate POV), but then why not simply cooperate a bit more with the community? Hopefully they’ll accept some criticism and suggestions.
Or even better: they could simply reuse all the work being done to officially package Chromium.

UPDATE: forgot to mention that the version string (something like “4.0.249.43-r34537”) doesn’t follow policy. Not a huge deal for a non-distributable package, but in the name of forward-compatibility – if Chrome ever becomes fully open-source – it could be smart to adopt something like “4.0.249.43-0.x”.

Nationality wars

2009.10.01 13:45 by Leo Antunes - 9 Comments

After seeing bubulle’s post on the statistics per country in Debian I started wondering about how the statistics were made. They probably take into consideration the Country field in the LDAP, but this seems a bit off since there’s a considerable number of DDs living abroad.
This hit me since I should probably count as BR, but live in DE. I’m personally skewing the statistics!

I know this is totally meaningless, but perhaps we could add a “nationality” field to the LDAP, just to make the competition a bit more precise! ;)

A new-new laptop

2009.08.15 19:54 by Leo Antunes - 8 Comments

After more than one problem with the old one and thanks to no small amount of luck, I got a new laptop, just six months after getting the last new laptop.

The new Acer Aspire Timeline 3810T is pretty nice and I got it at a surprise sale, so it was definitely worth it.
This time around I had – at least partially – done my homework and already knew about some possible hardware issues. Installing Debian wasn’t problem-free, but it was certainly made harder by my stubborn expedition into let’s-try-it-the-stupid-way-land (not unlike my recent run-in with dpkg):
Lenny’s kernel didn’t recognize the network cards and the daily-built installer images didn’t even boot (perhaps related to #541115), so I diligently spent the next couple of hours trying to build my own Frankenstein version of d-i with varied levels of failure. This didn’t accomplish much besides leaving me with a renewed respect for the d-i team.
In the end I gave up looking for ways to complicate things, simply installed a base Lenny system and copied a new kernel package via USB-stick (actually compiled my own 2.6.31-rc5, since 2.6.30 still didn’t correctly support the atl1c Ethernet card: recognized, but non-working).

After that slightly bumpy start, everything went totally smooth. [UPDATE: I just noticed the internal microphone wasn’t working. Adding “option snd-hda-intel model=fujitsu” to modprobe’s configurations fixes the issue. It also works with model=eeepc-p901, but the sound quality was worse. I filed a bug on ALSA to support this out-of-the-box in the future.]

As for the IDE vs. AHCI problems reported in the Ubuntu help site, I don’t know if it affects the Lenny installer because I switched to IDE mode before installing and back to AHCI only when 2.6.31 was already running.

My quick overview of the laptop:

Pros:

  • The battery’s really nice: ~6 hours with wireless on, medium brightness and normal usage (including some quick compiling).
  • The screen’s also pretty sharp and the size seems to hit my personal sweet spot between too small to use and too big to carry.
  • The keyboard seems a bit strange at first, but after a few hours I’ve gotten totally used to it and now I actually find it a positive point. It’s pretty hard to find a nice keyboard on a small(ish) laptop.
  • It isn’t a performance machine, but it’s a sensibly quicker and more responsive than all netbooks I’ve tried.

Cons:

  • I haven’t tried it very hard, but I didn’t manage to make suspend work. Still haven’t given up on it, though… [UPDATE: suspend works like a charm with the solution found in this bug report]
  • Multi-touch support doesn’t feel very usable, but perhaps it’s just hard to master (it could also be lack of tuning on the synclient settings)
  • The touchpad buttons are annoyingly a single piece of plastic. That means it’s pretty hard to press both at the same time to use 3rd button emulation (in case multi-touch doesn’t cut it for you).
  • Even thought the CPU apparently has the VT extension, it seems to be disabled in the BIOS (tested versions 1.04 and 1.10).[UPDATE: as seen in the comments, there are a couple of workarounds] [UPDATE #2: BIOS v1.14 seems to enable it.]
  • For those whose FOSS principles matter: the wireless LAN requires the non-free iwlwifi firmware.

It may seem like a lot of cons, but I’m pretty happy with it. Perhaps it’s just my frustration with the old laptop making the new one look better, or perhaps it’s just my newgadgetophilia speaking.
Regardless, the final test drive will be next week’s FrOSCon.

Restoring a wiped out dpkg status file

2009.08.13 18:23 by Leo Antunes - 6 Comments

UPDATE: Nevermind, nothing to see here, move along… Steve Kemp helpfully pointed out to me the obvious thing I had missed: status-old isn’t the only backup, there’s /var/backups/dpkg.status.*! Oops… doubly stupid.

After seeing madduck’s post and feeling my dpkg was certainly not as quick as it used to be, I decided to try the suggested status-file cleanup.

Since madduck is an old-time Debian developer (actually just one year longer than I am, but certainly way more active) I just assumed he’d have better understanding of dpkg’s inner workings than I do, so I blindly – and wrongly – copy-pasted his code and managed to erase my dpkg status file.
No backups were made out of sheer trust-induced stupidity and the status-old file was somehow also nuked, probably because of something I ran before noticing the problem.

It’s obviously not his fault that I didn’t pay attention to what I was doing, but by then I had royally messed up my machine, basically nuking dpkg, so I had to come up with this ugly little script to try and rebuild the status file.
If someone else managed to do the same absurd mistake, this could help.

#!/bin/bash
 
ls -1 /var/lib/dpkg/info/*.list | sed -r 's/.*\/(.*).list$/\1/' | while read PACKAGE; do 
	echo Package: $PACKAGE
	if [ -d /usr/share/doc/$PACKAGE ]; then 
		if [ -f /usr/share/doc/$PACKAGE/changelog.Debian.gz ]; then
			VERSION=`zcat /usr/share/doc/$PACKAGE/changelog.Debian.gz | head -1 | sed -r 's/.*\((.*?)\).*/\1/'`
		elif [ -f /usr/share/doc/$PACKAGE/changelog.Debian ]; then # downfall of the ia32-* hack
			VERSION=`head -1 /usr/share/doc/$PACKAGE/changelog.Debian | sed -r 's/.*\((.*?)\).*/\1/'`
		elif [ -f /usr/share/doc/$PACKAGE/changelog.gz ]; then
			VERSION=`zcat /usr/share/doc/$PACKAGE/changelog.gz | head -1 | sed -r 's/.*\((.*?)\).*/\1/'`
		else
			VERSION=0 # force upgrade, probably locally-built
		fi
 
		echo Status: install ok installed
		echo Version: ${VERSION}
		STRIP_FIELDS="Version|Package|Size|Filename|MD5sum|SHA1|SHA256|Tag|Task"
		CONFFILES_LIST=conffiles
	else
		echo Status: deinstall ok config-files
		STRIP_FIELDS="Package|Size|Filename|MD5sum|SHA1|SHA256|Tag|Task"
		# in this case we treat all remaining files as conffiles
		# (if there are no docs, there's no .conffiles either)
		CONFFILES_LIST=list
	fi
	if [ -s /var/lib/dpkg/info/${PACKAGE}.${CONFFILES_LIST} ]; then
		echo Conffiles:
		cat /var/lib/dpkg/info/${PACKAGE}.${CONFFILES_LIST} | while read CONFFILE; do
			if [ -f $CONFFILE ]; then
				echo " $CONFFILE `md5sum $CONFFILE | awk '{ print $1 }'`"; 
			fi
		done
	fi
	# "grep-available --invert-show" doesn't work as expected, so we grep the fields out
	(grep-aptavail --mmap -P $PACKAGE -X || (echo package $PACKAGE not found, leaving minimal entry 1>&2 ; echo -e "Version: 0+borkdstatus\n")) | grep -Ev "^($STRIP_FIELDS):"
done

Known limitations:

  • Needs root access to create some conffile md5sums
  • Can’t detect virtual packages, like nvidia-kernel-* stuff and probably everything created with module-assistant. A reinstall of the created packages in /usr/src/*.deb should suffice
  • Some packages do some version black-magic in the changelog (gcc-defaults comes to mind). I couldn’t find a better way to get the actual installed version, but a dist-upgrade after restoring the file should just re-install the affected packages.
  • Won’t correctly detect packages in an intermediary state like “unpacked, but not configured” (haven’t tested this)
  • Can’t detect purged packages at all, though this shouldn’t be a problem

Did I miss something? Is there a tool or a dpkg option that does this in a smarter/easier way?

Debian from Mars

2009.07.18 16:33 by Leo Antunes - 0 Comment

It had been a long time since I last saw it, so I had totally forgotten how stupid, trashy and cliche Mars Attacks was.

I still find it funny thought, in that same stupid way, but what actually got my attention this time around were the many Debian logos in the disguised Martian’s dress:

Mars Attacks

Not a particularly interesting coincidence, but made me laugh anyway.

PS.: first Debian Planet post. Yeah, I know, could have been a bit more productive…

“Social network” before someone invented the term

2009.07.12 17:39 by Leo Antunes - 0 Comment

As part of a bigger change that has been going on for the past couple of years, I’ve decided to get more socially involved with the projects on which I up until now only superficially took part.

The plan includes:

  • Finally going to events in my area of work (like FOSDEM and LinuxTag, perhaps even DebConf one day…)
  • Using the opportunities provided by the idea above to better integrate my GPG key in the Web of Trust (taking the chance to create a new one)
  • Doing a bit more Debian work and perhaps even participating a bit more vocally (I’ve always been a not very productive lurker)
  • I’m also toying with the idea of adding some parts of this blog to the Debian Planet to force myself to produce a bit more visible work, but I’m not sure I wanna face the flames yet

Let’s see how far I can take this…