[01:21] Where's UDS this year? Some canonical dude just emailed me offering to pay for my travel and board. [01:21] Oh, it says in the subject: "Orlando" [01:21] twb: florida again irc. [01:21] er, iirc. [01:21] Yes, there. [01:21] No way I'm going near .us [01:56] twb: why not? free trip and all... [01:59] Well, it boils down to 1) I don't like Ubuntu; 2) I *really* don't like USA; and 3) I don't deal well with meatspace. [02:04] twb: you're funny :P [02:05] jdstrand: do I need to wave https://secure.wikimedia.org/wikipedia/en/wiki/Unix_hater%27s_handbook under your nose? [02:06] twb: apparently so. I've actually not read that [02:06] * jdstrand adds to his todo [02:07] I do recall coming across it in various places, but never actually read it [02:07] twb: honest answer. I can appreciate that. [02:07] It says something like "we hate unix not out of ignorance, but out of experience. Only people who deal with its idiocies every day can truly appreciate how horrible it is" [02:07] heheh [02:08] I definitely need to read it :) [02:15] "see Peter Norvig’s detailed argument that Python is Scheme with funky syntax." [02:15] No, esr, it isn't. Case in point: call/cc and TCO. [02:15] (http://esr.ibiblio.org/?p=538, linked from the above wiki page) [03:45] New bug: #844478 in openldap (main) "apt upgrade exits on error with slapd_2.4.21-0ubuntu5.5_amd64.deb" [Undecided,New] https://launchpad.net/bugs/844478 [05:16] quit [07:48] morning [08:08] any opinions on zenoss vs opsview for monitoring? [08:15] collectd [08:40] I like twb, he is suitably angry. [08:40] Daviey: (on reflection, I suppose kees' security work is mostly good.) [08:41] hi all [08:41] Most other stuff just annoys me though [08:41] Early adoption of slapd cn=config databases, for example [08:42] And because I only see LTS releases, usually by the time something affects me, that's already been the way Ubuntu has done it for two years [08:42] Anyway, really going home now. [08:42] twb: This UDS is planning for the next LTS. :) [08:42] Daviey: yeah, but e.g. unity is already in [08:42] twb: Yeah, we did gamble with slapd.. Some like it, others hate it. [08:43] twb: Yeah, we are having unity on Server this time. [08:43] it looks pretty good in ascii. [08:43] I have end users [08:43] They have netbooting diskless workstations. They are prisoners. In a prison. [08:43] I'm not looking forward to retraining them to switch to unity. [08:43] heh [08:44] twb: I'm really not convinced it will be /that/ much pain. [08:44] Yeah, that might be a bad example [08:44] Or say having to make sure 3D is working because I can't just replace unity with metacity like I could with compiz [08:44] evolution -> thunderbird probably more painful. [08:44] But they don't /need/ to switch. [08:45] Daviey: btdt [08:45] twb: Ah, already use tbird? [08:45] And we are running ephy because sqlite3 was having problems with either NFS or prisoners just pulling the plug out rather than doing a "clean" shutdown [08:45] *sqlite3 under ff [08:46] twb: Well do sleep on your invite.. you are most welcome. [08:46] And then ephy/webkit has a problem with authenticated proxies, where it displays the proxy error and then the real page beneath it... [08:46] Not that I blame ubuntu for that [08:47] doesn't sqlite3 say in large letters not to use it with NFS [08:47] rbasak: yep [08:47] * rbasak never liked NFS [08:47] rbasak: and ff hard-depends on using sqlite3 out the wazoo [08:47] the alternative was CIFS and I didn't want to deal with machine accounts [08:47] I did try kerberized nfsv4 but I ran out of time and money before it actually worked [08:48] I would either forward the screen or have a local disk [08:48] s/disk/ramdisk/ if you like [08:48] shame [08:48] I'd quite like to get kerberized SMB2 running in a homogeneous debian/ubuntu environment, but samba4 isn't ready and it's all too hard [08:48] rbasak: forwarding the screens isn't as scalable [08:49] twb: If/when you do do that, i'd love to read a write up of it. :) [08:49] twb: Have you tried LTSP? [08:49] twb: but basic stuff will work without immense pain [08:49] Unfortunately LTSP was still at 4.0 when I built the existing infrastructure, and we are still using it out of inertia [08:50] I have rolled out a couple of small LTSP5 and debian-live sites [08:50] TeTeT: hello there [08:50] hi koolhead11 [08:50] rbasak: oh and I do run ff over the network here, because I won't allow anything that bloated on my own desktop, and that one line is struggle-central, because ff is so bad [08:51] in general, doing anything unusual results in pain, so unless it's central to what I'm doing, I don't do it [08:51] twb: You should do this, http://lwn.net/Articles/262570/ [08:51] I do it deliberately so I can file snarky bug reports [08:52] Daviey: I know RMS' browsing habits [08:52] My main browse is emacs, tho [08:52] It is very efficient use of your time :) [08:52] Daviey: speaking of pain, qemu and fifos! [08:53] AFAICT, if there is a buffer it's not bigger than 8M [08:53] And not listening on the fifo will cause qemu to throw stuff away [08:53] Isn't buffering the kernel's problem? [08:53] like ulimit [08:53] (either that or it's hanging the system) [08:54] I think it's the former though [08:54] -q The maximum number of bytes in POSIX message queues ? [08:54] I guess that's IPC not fifo [08:54] so ignore me [08:54] twb: other ideas for bug 832507, welcome [08:54] Daviey: Error: Could not parse data returned by Launchpad: HTTP Error 500: Internal Server Error [08:54] *sigh* [08:54] haha [08:54] Also it won't start the system unless there is a listener, but that's not too bad [08:55] I've found the code, it just tries a write(2) and if that fails it throws it away AFAICT [08:55] I get that too http://paste.debian.net/128809/ [08:55] bug 832507 [08:55] Launchpad bug 832507 in nova "console.log grows indefinitely" [High,In progress] https://launchpad.net/bugs/832507 [08:55] rbasak: can't you just use udp ports or something? [08:56] Daviey: I call savelog in the init script's start job [08:56] At least, in the related lxc case [08:56] http://paste.debian.net/128810/ [08:56] twb: The problem is that a guest can fill up the hosts hard disk, with cat /dev/urandom > /dev/ttyS0 , from within the instance. [08:56] twb: udp ports how? [08:56] Daviey: ah, DOS nice [08:56] rbasak: I dunno [08:56] Sorry, what's the problem now? [08:56] I thought we had a way forward? [08:56] soren: seems not. [08:57] How come? [08:57] well hang on, I didn't say that :) [08:57] Obviously the solution is to mount a tmpfs on /var/log/libvirt-bin :P [08:57] -osize=8M [08:57] I was just brushing up on what the actual behaviour wasw [08:57] I'm not fully clear on soren's plan but now I might be capable of understanding it :) [08:57] soren: Ah, might have jumped too fast. [08:58] Oh, I see, it's the same problem [08:58] rbasak: I thought you were using -net blah to set up some kind of handy-dandy fifo-backed thing [08:58] I thought we would just tell kvm to output to a fifo and read from that. Leave it to nova to implement a ringbuffer-style behaviour. [08:58] soren, where and how is the fifo going to be listened to? Only on a get_console_output call, or periodically too, and is the fifo going to get persistently held open or opened and closed? [08:58] soren: pump it into logger(1) [08:59] If Nova dies and the guest fills up the buffer and kvm can't deal with that in a nice way, screw it. They did this to themselves. [08:59] Then it becomes rsyslog's problem [08:59] rbasak: Hold it open, read from it periodically *and* on get_console_output. [09:00] rbasak: That'll make sure we keep flushing it even if noone calls get_console_output, but someone calling get_console_output will also get completely up-to-date responses. [09:00] OK and where do we write the data that we read, and how are we managing the space usage of that? [09:00] Flush it out the filesystem. [09:00] Imposing a limit on its size. [09:00] to a console.log file that can grow indefinitely? :-P [09:01] ah ok [09:01] What do we do if it hits the limit? [09:01] All logs can grow indefinitely [09:01] That's what logrotate is for [09:01] Pretend it's a ringbuffer. [09:01] The issue just becomes can you -HUP the writer to make it acquire a new fd [09:01] So just seek to the beginning again? [09:01] and are you expecting get_console_output to grok the ringbuffer and start reading at the right point? [09:02] I'm expecting everything to do The Right Thing[tm] :) [09:02] It's not different from e.g. DOSsing the logfile by making sshd emit a "rejected connection for user root from host 1.2.3.4" messages [09:03] twb: We don't want to let these logs grow indefinitely.. and logrotate doesn't do that either. By default, at least. It expires old logs and throws them away. [09:03] well logrotate cannot act fast enough. [09:04] rbasak: It's probably worth investigating how big of a message you can get through the message queue (which is how the console output will make its way from the compute node to the API node). [09:04] rotatelog can, as it's piped through.. [09:04] Daviey: why? How is it different from filling the logs via some other program? [09:04] but i'd rather rip my head off than use rotatelogs [09:04] twb: Isn't that the same reason people often put /var/ on a seperate partition? [09:05] Indeed [09:05] The difference here, the server admin currently has no way of controlling the speed of the log writes. [09:05] He doesn't have that with e.g. sshd either [09:05] Unless there's something in rsyslog I'm unaware of [09:06] Hell, apache would probably be an even better exaample, because it logs user-supplied string by default [09:06] OK so I need to patch nova to: 1) create a fifo and open it persistently before it calls libvirt to start the process (I assume right now it relies on qemu to create console.log; we'd be creating that as a fifo in advance). 2) Periodically suck data out of the fifo and give it to the handler. 3) Also do step 2 before processing get_console_output. 4) Write a handler that will write round robin to a real console.log, which will wrap if seek position [09:06] goes above a limit, and keep track of where it is in memory (so a ringbuffer implementation managed in memory with a disk data store) [09:06] So make requests as fast as you can with a 1024kB-long user-agent [09:06] 5) get_console_output now needs to read through the ringbuffer implementation [09:06] What I'm geetting at here is: you're not special, everybody has this problem [09:07] Rolling an app-specific fix is silly [09:07] twb: it'd break the API [09:07] twb: get_console_log really needs to output the last x bytes written to the console [09:07] rbasak: throw away the API then ;-) [09:07] twb: what happens if the call comes just after the log was rotated? [09:07] twb: We're perfectly happy to discard old data. [09:07] Oh, hang on, I think I misunderstood [09:08] We only /need/ 16K IMO. [09:08] You're saying that ttyS0 in the guest is directly connected to a file on the server? [09:08] twb: currently, yes [09:08] And you can't connect it to a pty instead? [09:08] Daviey: Whuh? That won't even fit all of the bootup-messages. [09:08] twb: it can be done but painfully [09:08] twb: How would that help? [09:08] I guess becaus then you don't get any history until you connected [09:09] s/until/before/ [09:09] THat's what I'm doing for my libvirt KVM VMs, so I don't have to use VNC [09:09] This console output stuff is read-only. [09:09] OK, let me get even weirder [09:09] Using a pty sounds like adding another layer of problems. [09:09] Turn that off, and instead use netconsole.ko in the guest [09:10] Can't. [09:10] It's not ours to control. [09:10] So the VM could be windows or something? [09:10] This is the cloud. WE provide infrastrucute, random nutjobs run their guests. [09:10] OK [09:11] Right now, the contract is: Shove the stuff into the virtual serial port, and it'll magically turn up in GetConsoleOuput's response. [09:11] soren: sorry, 64K [09:11] ..and we can't really change that contract. [09:11] Well, we can, but we need much better arguments than have been made here. [09:11] Since that's what all the existing EC2 images do and losing compatibility with them over something like this sounds like a really bad idea. [09:12] soren: what do you think of my plan (which is just my understanding of your plan with the details filled out)? Will it work? Would you accept it? [09:12] soren: Hah, smoser has been pushing for ages that openstack should just provide the hardware.. not this poking, reaching in lark that has been punted. [09:12] rbasak: It sounds good, yes. [09:13] Daviey: And I completely agree with that. [09:13] the only catch I can see is that the ringbuffer management is in memory so if nova dies then the stored console log is no longer readable (it'll wrap at an unknown location) [09:13] Yeah, just put it in the file. [09:13] Like you suggested a couple of days ago. [09:13] and of course if nova does then we'll lose the fifo fd and that'll mess things up [09:14] Oh, OK :) [09:14] So that'll make the ringbuffer robust [09:14] but what about re-opening the fifo if nova is restarted? [09:14] Just make the first line something like: [09:15] rbasak: What about it? [09:15] soren: Do you have time to discuss this, shouldn't you be arguing about what code hosting to use? :) [09:15] soren: I presume I'll need to implement that, but I don't know where or how [09:15] OK, REALLY leaving now [09:15] Daviey: Everyone else is asleep. I can do whatever I want. When they turn up, I'll get back to bitching about tooling. [09:15] twb: have fun o/ [09:15] soren: the first line would have to be a fixed length [09:15] soren: cool :) [09:16] rbasak: Just open it again when nova starts. It has code already to pick up where it left off. [09:16] rbasak: That would certainly make it easier. [09:16] OK so that's a step 6 in my plan [09:17] rbasak: "<0-padded 64 bit hex max_length> <0-padded 64 bit hex current_tail>\n" [09:17] I suppose I could pad with zeroes to the same length as max_length [09:17] why hex? [09:18] Because 64 bit is a predictable lenght in hex. [09:18] Not so much in decimal. [09:18] oh, one other thing about the disk ringbuffer format [09:18] You can go with octal if you want. [09:18] Or binary. Just not decimal :) [09:18] If I use ascii then it'll corrupt if killed [09:18] Why? [09:19] I can't update it atomically [09:19] What *can* you update atomically? [09:19] If I use a binary int then it will [09:19] eh? [09:20] Maybe it's overkill [09:20] Why is it less atomic if you encode it in ASCII? [09:20] can be improved over time, having /something/ would be nice for first fix :) [09:20] ascii will cover many more bytes [09:21] Still *well* within a filesystem block. [09:21] too many layers before it gets to a filesystem block. is everything aligned before then? [09:21] anyway, as Daviey says [09:21] I'll find or implement a ringbuffer class [09:22] We could fix that later :) [09:22] You're arguing that writing 8 bytes rather than 16 bytes makes it more atomic? [09:22] yay memory tears. [09:22] :P [09:22] I'm arguing that atomic_t is atomic and nothing else is [09:22] (guaranteed) [09:23] Not sure what relevance atomic_t's have here? [09:23] What am I missing? [09:23] atomic_t sounds like wicked name for a rapper, though. [09:33] https://bugs.launchpad.net/nova/+bug/832507/comments/4 [09:33] Launchpad bug 832507 in nova "console.log grows indefinitely" [High,In progress] [09:33] Is this OK with everyone? [09:34] Yes. [09:34] looks good [09:34] cool [09:35] Implementation details that are a bit unclear to me: doing periodic jobs, and the restart logic [09:35] I might need some pointers on the way if that's OK soren? [09:35] does it makes sense to do system lockdown with gconf anymore? [09:35] Sure. [09:35] rbasak: restart logic might be for free. [09:36] koolhead11: gconf? wat? [09:36] Daviey: I think I see what you mean [09:36] * rbasak isn't familiar with the Nova source yet [09:36] rbasak: You ca use my bzr branch for inspiration where the entry point is to mk the fifo [09:37] I didn't test what happens if the fifo reader blocks so the fifo buffer fills (but still has it open). qemu will either block or it won't. I don't think it matters as we'll suck at a reasonable periodic rate and if the guest wants to dump tons to the console it's reasonable for it to be slowed down [09:37] thanks Daviey [09:38] Daviey: for ubuntu desktop in lockdown enviornment [09:38] soren: What would be a good example of a scheduled task to use? [09:38] rbasak: you should be able to first just read directly from the fifo with minor changes to my branch.. [09:39] difference between a mknod and mkfifo is small :) [09:40] Daviey: nova.compute.manager has a period_tasks that does various things. [09:40] err... [09:40] periodic_tasks [09:40] Daviey: We should extend it to call driver specific periodic_tasks. [09:40] rbasak: Get that working first, then think about changing the behaviour to schedule a task to read and put to txt file.. Then make get-console read from the txt file, rather than the fifo (the branch i have edits the read log part.) [09:40] Daviey: I see it, thanks [09:40] Daviey: why do we need root to create the fifo? [09:41] rbasak: Only root can mknod. [09:41] rbasak: So Daviey needed it. [09:41] We might not need it. [09:41] yeah, drop that [09:41] (since we're only mkfifo'ing, but I'm not completely sure we're in the clear anyway) [09:41] It depends who the guest is going to run as. [09:42] you can still chown a fifo :/ [09:42] negronjl: hey - please give me a ping re tomcat formulas when you start your day [09:43] Daviey: I'm only seeing the fifo being opened, don't see anything about reading it [09:43] Daviey: have you pushed? [09:43] Daviey: Sure, sure. I'm just pondering who needs to own it. [09:43] http://bazaar.launchpad.net/~davewalker/nova/832507_with_emlog/revision/1509 is the only revision I can see [09:43] rbasak: def _dump_file(self, fpath): [09:43] Daviey: Have you used the dashboard package, by the way? [09:43] Daviey: oh, right [09:44] soren: no, but i believe it is known to be broken [09:44] rbasak: I had to make changes to that to make it not block, i don't know if a fifo will need that like my nod did. [09:45] Daviey: Ah. [09:45] Daviey: yeah I think it will, otherwise it'll just hang there waiting for all console output ever [09:45] soren: Have you tried it the dash? [09:45] A long, long time ago. [09:45] Daviey: non-blocking using Python file objects is a bit dodgy actually, it might not work and I might need to use os.read instead [09:46] soren: from the package? [09:46] Daviey: Nope. [09:46] soren: I don't believe we can currently get ec2 creds from it, which is a pain. [09:46] Daviey: WEll,... [09:46] Daviey: Yes, I've *tried* trying it. [09:46] rbasak: So it isn't using normal os, it's overidden by greenlet [09:47] err, eventlet [09:50] Daviey: I'm not familiar with that, what are the implications? [09:51] Oh, dear. [09:52] rbasak: Pretend like you don't know the first thing about blocking and non-blocking I/O. [09:52] rbasak: Because eventlet will screw with all of that. [09:52] So how should I suck all available data out of the fifo but not block? [09:52] Do it like someone who hasn't a clue there's such a thing a blocking or non-blocking I/O. [09:52] will what Daviey has already work? [09:53] Just read. [09:53] Haven't looked at it. [09:53] soren: is there something like nova --version ? [09:53] koolhead11: There ought to be, but there probably isn't. We log the version in the logfiles, but I don't think we expose it that way. [09:54] soren: I don't see how I can code in ignorance like that. Will my call block or won't it? [09:54] soren dpkg -l says 2011.3. something [09:54] rbasak: So what i have in that for reading, doesn't block [09:54] if it blocks without it, add it in :) [09:54] rbasak: Yes. [09:55] rbasak: just opening it with NONBLOCK did infact block, thanks to eventlet [09:55] jamespage: hellos [09:55] rbasak: I'm not trying to be more of an arse to you than eventlet is to everyone else. You just read and cross your fingers hoping that eventlet does something vaguely reasonable on the backend. [09:56] rbasak: soren is right.. I couldn't work out why the hell it was blocking when it was os.open'd NONBLOCK.. it was only when i started inspecting the object that i realised it wasn't normal os [09:56] * jamespage waves at koolhead11 [09:57] frustrating() [09:57] Presumably someone chose to use eventlet here, and presumably whoever that is knows it well. Can we ask him how we should read from a FIFO? [09:57] * koolhead11 bows to TeTeT: [09:57] jamespage: wassup? [09:57] while fifo.read(): [09:57] do_stuff_with_it() [09:58] and that won't block when the fifo is starved? [09:58] Depends on what "that" is. [09:58] Nova, no. Your loop, yes. PRobably. [09:58] rbasak: probably worth just trying it to see what happens? [09:58] suck it and see. :) [09:59] rbasak: You'd think that whoever chose it knew it really well. You'd be wrong. [09:59] rbasak: It was chosen because it made the code easier to read for people who didn't understand async code and non-blocking i/o and whatnot. [09:59] Daviey: I hate coding like that, can you tell? Otherwise it may break for an unknown unfathomable reason later, especially with stuff like this where we're heavily dependant on what's going on with the underlying fifo [09:59] Why they're more important than my sanity, I don't know. [10:00] This was a chance to argue endlessly about something, so of course we did. [10:01] rbasak: Hey, if the unit tests pass, ship it.. that is the upstream workflow :P [10:01] * rbasak wonders how many race conditions there are in nova at the moment [10:02] Daviey: Luckily, our test suite is awesome.... [10:02] Daviey: ....ly slow. [10:02] But I digress. [10:03] soren: well if rbasak makes a change that breaks a unit test, we just SKIP the unit test, right? [10:03] Daviey: Too obvious. Just remove it. [10:03] I can always "adjust" the test [10:03] heh [10:04] rbasak: Sorry, i was commenting on the fact that nova has history of disabling tests which are annoying and fail. [10:04] This was yet another area that upstream were able to argue the moral toss about. [10:04] And I have a history of crying myself to sleep. [10:04] These facts are related. === mendel__ is now known as mendel_ [10:12] New bug: #836664 in python-anyjson (main) "[MIR] python-anyjson" [Undecided,Fix released] https://launchpad.net/bugs/836664 [10:27] soren: http://paste.ubuntu.com/685140/ nova version :-> http://paste.ubuntu.com/685142/ [10:29] koolhead11: Zones are mysterious to me. I suggest you ask someone like sandywalsh. [10:31] Daviey: i have my fingures crossed, we will be testing new oneiric images via cobbler :) [10:33] koolhead11: cool [10:36] https://bugs.launchpad.net/ubuntu/+source/asterisk/+bug/831228 [10:36] Launchpad bug 831228 in asterisk "asterisk version 1:1.8.3.3-1ubuntu1 failed to build in oneiric" [High,Confirmed] [10:36] This is a problem with the libc-client.so build [10:37] Even if I rebuild the debian binary, it's not import needed symbols [10:37] (but the debian binary has it right) [10:37] rbasak: Have you come across ld --as-needed? [10:37] no [10:38] rbasak: http://wiki.debian.org/ToolChain/DSOLinking [10:39] rbasak: which implies that uw-imap needs an extra LDFLAG? [10:39] yeah, maybe [10:40] is there a reason for debian and ubuntu to behave dfferently? [10:40] I haven't tested to see if debian rebuilds it right or not [10:40] rbasak: Debian will move to ld --as-needed one day it's suspected. [10:41] Some people feel it's easier for us to make the transsiiton first, then Debian. [10:42] Man, if we had to wait for Debian before we tried interesting toolchain changes... [10:42] So what's the current status? [10:45] It doesn't seem to just be new libraries [10:45] It's _all_ libraries [10:48] rbasak: yup! Which is the main reason we have so many FTBFS's [10:48] fwiw, this was tried last cycle - and was reverted before release. [10:48] It could happen again, but i'm doubtful. [10:56] yeah -Wl,--no-as-needed fixes it [10:56] so now I just have to find a proper solution [10:59] rbasak: well that will be ok for a last resort, just need to find out what the missing lib is. [11:00] Daviey: well, all of them are missing [11:00] that's the odd thing [11:00] even though they are specified on that same line [11:03] rbasak: it culd be an ordering issue then [11:03] could* [11:03] the current line is: gcc --shared -Wl,--no-as-needed,-soname,libc-client.so.$(VERSION) $(PAMLDFLAGS) -lc $(EXTRALDFLAGS) $(SSLLDFLAGS) -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -o [11:03] (I added --no-as-needed) [11:04] without --no-as-needed, that results in ldd reporting only libc and ld.so, linux-gate etc [11:04] -o needs to be before LDFLAGS [11:04] 12:04 -!- doko_ [~doko@dslb-088-073-086-171.pools.arcor-ip.net] has quit [DISGUSTED] [11:04] that makes a difference? [11:04] yah! [11:05] OK then the build system has problem [11:05] rbasak: For example, http://launchpadlibrarian.net/79186443/monkey_0.9.3-1_0.9.3-1ubuntu1.diff.gz [11:05] It's really a variable that's being set, it assumes that -o is at the end [11:05] Yeah, that is the bug [11:07] http://paste.ubuntu.com/685163/ look at line 180 [11:07] To fix this, the build system is going to need a radical change [11:07] echo "$(ARRC) $(ARCHIVE) $(BINARIES);$(RANLIB) $(ARCHIVE)" > ARCHIVE [11:08] looks like that's how it works === rickspencer3__ is now known as rickspencer3 [11:09] I suppose I could add an ARRC_AFTER_ARCHIVE or something [11:10] :/ [11:11] It does look like a rather insane build system === koolhead11 is now known as koolhead17 [11:12] rbasak: :( [11:25] TeTeT: need your help. ping me back when your around. [11:34] it does feel a bit odd that to fix an asterisk ftbfs I'm hacking an imap library makefile [11:34] wtf does asterisk do with imap anyway? [11:35] * rbasak resists running configure with --without-imap [11:36]