Man ports Etch mail server packages to Chinook; melts own brain
 

This is a report of a success, of sorts, rather than a request for help. But it's likely that there are much, much, much better solutions to my various problems, so pipe up and let me know what they are.

The situation was as follows.

I'm going to be travelling round the world, through places where finding a public hotspot is simply not an option. The best I'll manage is occasional access to internet cafes. That means the only connection to the outside world my n810 will have is via USB mass storage.

So how do I get my mail? I have a cron job on my server that downloads in full all articles from my RSS feeds and uploads them to my mail server. I'd like to retrieve that email for reading on the road. How to do that via USB mass storage?

Well it's easy enough to retrieve new mail to the card - use rsync (although the devil is in the details there, especially for mail going the other way). But how do I read that mail on the n810? Claws allegedly has support for reading local maildir, but in fact it only seems to work with mbox. And anyway, claws is pretty horrid. Modest is somewhat better, but it doesn't seem to have support for reading a local maildir.

So there seemed nothing for it but to run a mail server on the device itself. Then configure modest to connect to nokia-n810-50-2, and voila, I can read email without a network connection. That's the theory.

So I therefore undertook to find a mail server from the Etch repository and rebuild the package under scratchbox. Yes, I could just compile the binary and package it up myself, but I like having the Debian developers backing me up. They've already found and dealt with all of the tricks and caveats, and so it's better to bring over their work cleanly.

So my approach worked like this:

build-package (package) {
apt-get source package
while ("dpkg-buildpackage package" complains about dependency) {
build-package(unmet-build-dependency)
}
while ("dpkg-buildpackage package" fails) {
hack-package
}
while ("dpkg --install package" complains about dependency) {
build-package(unmet-install-dependency)
}
}

Plug "dovecot" or "courier" into the start of that function, and recurse away. What could be simpler?

A week, over 300 .debs, and a lot of swearing later, I eventually managed to get this to actually work. One package depends on another, which requires a library, that is documented with ghostscript and won't build unless its there, and before you know it you're trying to compile x.org. It's really, really embarrassing how much time over the last week I sunk into this project instead of organising my holiday. But for better or worse, the results are available here:

http://apt.exon.name

(Although if too many people try to use it, they won't be for very long).

The net result is that I am able to "apt-get install dovecot-imapd libpam-modules". I tried courier, but it just doesn't wanna go. Dovecot is enough for the moment.

There are two hairy parts. First, you need to install libpam-modules as well. It's not a dependency in Debian, and I didn't want to mess with that in case there was a reason.

The second hairy part is that the Debian dovecot depends on having an inetd. I compiled openbsd-inetd, but it depends on update-inetd. As it happens, Nokia have smooshed that into the netbase package - but there's no "Provides:" line to make that clear. It tries to install a real update-inetd, which leads to:

Unpacking update-inetd (from .../update-inetd_4.27-0.5_all.deb) ...
dpkg: error processing /var/cache/apt/archives/update-inetd_4.27-0.5_all.deb (--unpack):
trying to overwrite `/usr/share/perl5/DebianNet.pm', which is also in package netbase

So I rebuilt netbase with nothing changed except the "Provides:" line:

http://apt.exon.name/pool/main/n/net....osso6_all.deb

(And if you install packages with names like "netbase" from random hackers on the internet pointing to random servers, you're mad.)

Once dovecot-imapd is installed, edit /etc/dovecot/dovecot.conf and set "protocols = imap" to enable the server. You will also want to add a user so that you can set a password.

If you have problems with this, well, sorry. I really don't have time to fix anything that goes wrong. On the plus side though, if you want to compile your own dovecot, there are a bunch of build dependencies and things in my repository that you can use to avoid all the pain I had to go through.

So, why don't you embarrass me even more by explaining how I could have knocked this off in an afternoon :-)

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

Wow great. I see several packages that I did not manage to build due to amazingly long list of dependencies and didn't want to do what you did.
libreadline5
gnutls

Actually there are some of your packages that already existed.
expect
perl
gtk1.2
libreadline4
tlc
tk
..
I just hope nothing strange happens if I have your repository and official one included.
You've even rebuilt xserver-xorg! :)


Did you use scratchbox?
I remember failing several times on libreadline5. This blocked me for several packages.
Also psmisc usually conflicts with busybox.
I'll try all this.

Thanks for sharing.

I think that would be too much if I would ask your diffs? Hum? :D

edit:
strange, I retried readline5 and it worked. Must have done something wrong last time.

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

Which is a simplified version of buildd:
http://www.debian.org/devel/buildd/

Example:
http://buildd.debian.org/fetch.cgi?p...amp=1202669296

But the hack-package is not implemented :)

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

Don't do that! It's a horrible hacked up mix of sarge and etch and whatever seemed like a good idea at the time. It will break your world and make you sad. Really only useful for satisfying your build dependencies so that you can build the packages you really want.

No, I haven't. Not for want of trying though! The X packages are just compatibility packages I think.

It would be very, very helpful if some kind soul would port xorg for real. It doesn't need to actually run, it's just the development libraries that are essential.
Yeah. It was extremely frustrating to get it up and running at first, the documentation is utter chaos. But after that it was pretty good. It's only when it came time to compile arch-specific perl packages that it really caused trouble.

There aren't all that many diffs. Instead, what I need to do is post my notes somewhere. These would be really useful for people (I used other people's extensively). But there's some stuff I need to redact before I put them online. I'll try to do that soon.

I knew there must be something like that. But so much stuff fails, I knew it wouldn't make things go all that much easier. There needs to be a driver at the wheel.

Mind you, I only realised about three quarters of the way through that there was an apt-get source command. I am way n00b.

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

Yes that's what I do also, I'm lazy to post the diffs (although if really requested, I will, to follow the gpl and hum the choice of my nick..)
Well, for the packages that made you really really swear, maybe post a quick note.

Actually you gave me the idea to port again on of my favorite app. I had failed last time but now it seems to work. About half the way, still about 20 dependencies to build :/

I thought about porting buildd also. Wouldn't be that bad.
Or make a hacked up buildd. Sometimes I forget at which level of dependency I am and what I have to build next :)

Hum a bit from sarge a bit from etch, you're a barbarian!

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

I really hope both of you heard of mud-builder before you started on your endeavors...

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

Nope, I hadn't heard of it, but then I don't read these forums much.

I'm not sure it would have done much for me though. Hosting isn't a problem for me, and having my own APT repository allows me to cause as much mayhem as I like in my own sandbox. Mostly what I did was hack out the guts of dependency packages until whatever was stopping them compiling was removed and I could move on. The resulting .debs are not fit for end-user use, so I wouldn't want to see them anywhere near repository.maemo.org.

However, it would be marvellous if someone would re-do the worst packages in mud, using my packages to avoid dependency hell. Stuff like the libsasl2/libldap2 circular dependency, or ghostscript. That would make life a lot easier for people who want to get some really useful packages built without needing to rebuild the world.

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

Well, don't look at me. I decided to do things the other way around. :)

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

same here, i wouldn't need it. not sure i understood really what it does?
what would be cool would be a search a la debian: packages.debian.org

When you're blocked because scratchbox segfaults, it gets more tricky.. :(

Re: Man ports Etch mail server packages to Chinook; melts own brain
 

As promised, my notes are here:

http://mat.exon.name/logs/maemo

By the way, I got courier to compile cleanly as well and it's on my server. But I haven't bothered testing it.