[09:16] <kraut> moin
[09:52] <stiv2k> how do i set a static ip for my server
[09:53] <stiv2k> nvm
[09:53] <stiv2k> <3 google
[10:44] <juliux> ood morning
[10:56] <Drazha> odd morning
[12:00] <baggito> odd afternoon
[12:05] <Drazha> soon enough
[12:06] <Drazha> it will be day
[12:06] <Drazha> and then evening
[12:06] <Drazha> and then....
[12:06] <Drazha> the night shall fall#
[12:07] <Drazha> so anyway...
[12:08] <Drazha> WHY Ubuntu Server?
[12:08] <baggito> because we're used to ubuntu now?
[12:08] <baggito> and have faith in their dogma
[12:08] <Drazha> just because of that?
[12:08] <Drazha> that dogma being?
[12:11] <baggito> mmmm
[12:11] <baggito> something about linux and humans
[12:12] <juliux> Drazha, ubuntu rocks, that is all, and pls no flamewars;)
[12:12] <Drazha> actually I am not trying to start a flamewar, honest to god
[12:12] <Drazha> I am just trying to understand, is all
[12:13] <juliux> Drazha, i use ubuntu on servers because i have ubuntu on all my desktop computers and i knwo how to work with ubuntu systems, so it is easier for me to have ubuntu on the server then debian or gentoo
[12:14] <juliux> Drazha, i only have to read one security liste, i only have to test the upgrades on one system
[12:14] <juliux> so its less work for me
[12:15] <baggito> that's basically my idea too
[12:15] <baggito> ubuntu on desktop, ubuntu on server
[12:15] <baggito> develop on desktop, deploy on server
[12:16] <baggito> it's much easier if you don't have to start dealing with package-version skew or trans-location of files
[12:16] <juliux> Drazha, and if i found a problem on my desktop i can fix it theren then i know that this problem can be also on my server but then i know how to fix it
[12:26] <Drazha> hm, ok, so lets say I find that ubuntu has an old version of some app
[12:26] <Drazha> i am back to compiling from scatch and sources?
[12:36] <soren> Drazha: Depends on the app.
[12:36] <juliux> Drazha, i also compile some apps. for example qmail
[12:36] <soren> Drazha: Generally, if you're the kind of person who needs a lot of recent software, you *really* want to be running the latest release.
[12:37] <soren> Drazha: And generally, the software in the lastest release should be quite recent.
[12:37] <soren> Drazha: Also, for some packages, it not really all that difficult to backport it yourself.
[12:37] <soren> Drazha: Are you thinking of any particular app or just asking a general question?
[12:39] <Drazha> just a general question
[12:39] <Drazha> you see, the only reason why I stay on the edge of development because a lot of security features are intriduced, such as in antispam etc...
[12:39] <Drazha> sometimes when one needs to upgrade its living hell
[12:39] <Drazha> so I kinda thought maybe freebsd would be kewl, but i have issues with that...
[12:40] <Drazha> and I havent used debian nor ubuntu that much in server variant to know much about issues such as upgrading etc
[12:41] <soren> Drazha: My upgrade habits are not really sane, so I can't say for sure, but I think generally upgrades are pretty smooth with Ubuntu Server.
[12:42] <soren> (I upgrade at some point during the development cycle, so that doesn't really count)
[12:42] <Drazha> ok so whats the difference between ubuntu desktop and server? no X stuff?
[12:42] <soren> Drazha: it's the same software repository, so the only real difference it the selection of software that gets installed by default. X for instance is not installed by default on servers.
[12:43] <Drazha> I see
[12:43] <Drazha> so just a package selection that is different
[12:43] <soren> Drazha: Yes.
[12:43] <Drazha> if I were silly, I could pretty much easily install just abount anything and make the box everything and nothing
[12:44] <soren> Drazha: Yes. You can easily take a server install and install gnome on it, and presto, it's a desktop! :)
[12:44] <soren> Drazha: Except for the different kernel, of course.
[12:44] <Drazha> a server desktop :)
[12:44] <soren> Drazha: The servers get a different kernel installed by default.
[12:44] <Drazha> hm, they develop a server kernel and a desktop kernel?
[12:44] <Drazha> hehe, this would not have to do with the recent scheduler conflict?
[12:44] <soren> Drazha: I can't remember all the differences, but stuff like using a different i/o scheduler and a lower HZ.
[12:45] <Drazha> :))
[12:45] <Drazha> oh well, I guess it does make sense
[12:45] <Drazha> but I guess one could install both kernels and switch if one is so concerned about that
[12:46] <Drazha> not that running a web app on a box with gnome on it makes sense, but what the hey
[12:46] <soren> Precisely. They share the same repository, so you're not tied into anything.
[12:48] <Drazha> which basically then boils down to, which default MTA is ubuntu using, for example?
[12:48] <soren> None :)
[12:48] <soren> We have a no-open-ports-by-default policy.
[12:48] <soren> ..so we don't install an MTA by default.
[12:48] <soren> Exim and Postfix are both in main.
[12:48] <Nafallo> hmm
[12:49] <Nafallo> do we still? :-)
[12:49] <soren> Nafallo: still what?
[12:49] <Nafallo> soren: have that policy. I thought 5353 had been opened.
[12:49] <soren> Nafallo: Ah, have a no-open-ports-by-default policy?
[12:50] <soren> Nafallo: mdns is a bit special :)
[12:50] <Nafallo> in what ways? :-P
[12:50] <Nafallo> it
[12:50] <Nafallo> it's still an open port
[12:50] <soren> Nafallo: You need to remember that even though we have a no-open-ports-by-default, we still have DNS and DHCP installed, for instance.
[12:51] <Nafallo> soren: do we really?
[12:51] <soren> Nafallo: clients.
[12:51] <soren> Nafallo: They listen for stuff on the network. That's how they work :)
[12:51] <Nafallo> soren: clients doesn't open ports be default no...
[12:51] <Nafallo> soren: dns doesn't listen. it asks.
[12:51] <soren> Nafallo: And how do you think the response gets back?
[12:51] <Nafallo> same with dhcp
[12:52] <Nafallo> soren: well, that's not what we mean by no open ports :-)
[12:52] <Nafallo> soren: ofcourse epiphany open ports when I try to talk to T/80 :-P
[12:52] <soren> Nafallo: That's different.
[12:52] <soren> Nafallo: It's TCP connections.
[12:52] <Drazha> hm
[12:53] <Drazha> well what about ssh? :) is that closed by default as well? :))
[12:53] <soren> Nafallo: Hang on, there's a wiki page about all of this.
[12:53] <soren> Drazha: Not installed.
[12:53] <Drazha> so how the heck do you get in your box remotely?
[12:53] <soren> Drazha: We ship it on the CD, so it's super easy to install it, but it's not installed by default.
[12:53] <Nafallo> soren: there is no open port for DNS on my client.
[12:53] <soren> Nafallo: Try making a dns query and watch your netstat.
[12:53] <Nafallo> soren: two udp for mdns and one for dhclient.
[12:54] <Nafallo> soren: sure, but that's not open by default.
[12:54] <soren> Nafallo: No, but it's not closed either.
[12:54] <Nafallo> soren: that's open on request.
[12:54] <Nafallo> soren: it is closed by default :-)
[12:54] <Nafallo> soren: if the client does not do a request it's closed.
[12:54] <soren> Nafallo: Yes, but the point is that when it's open, anyone can send stuff to it that might exploit a security hole.
[12:55] <Nafallo> agreed. but that's a pretty small chance they'll be able to see the port open and get to send data their in the time-frame :-)
[12:55] <Nafallo> there even
[12:56] <Drazha> hm, whats mdns anyway? I've seen it being mentioned before but was to lazy to google it
[12:56] <Nafallo> automatic service discovery
[12:57] <soren> Nafallo: A small chance is all a dedicated malicious person needs.
[12:58] <Nafallo> well, you can't talk to thinks if you don't listen for answers. if you're that paranoid you shouldn't even have the PC connected to electrical power.
[12:58] <Nafallo> s/nk/ng/
[12:58] <soren> Nafallo: I'm not suggesting that we should disable dns or dhcp.
[12:58] <Nafallo> good ;-)
[12:58] <soren> Nafallo: I'm just pointing out that there *is* in fact stuff that evil-doers can connect to if they want.
[12:59] <Nafallo> sure, but most scriptkiddies can't :-)
[12:59] <Nafallo> the chance getting struck by those are fairly much higher.
[12:59] <soren> Nafallo: Sure they can. Just keep flooding until it opens up.
[01:00] <soren> Nafallo: a) the code has been audited many times, b) we can't really live without DNS capabilities.
[01:00] <soren> Nafallo: Hence, we accept this (minimal) risk.
[01:00] <Nafallo> then scriptkiddies must have became much better in the last years then :-)
[01:00] <soren> Nafallo: They just have more bandwidth :)
[01:01] <Nafallo> hm. food. bbl.
[01:01] <soren> Nafallo: The mdns code has been audited, and the impact of a compromise has been deemed very small.
[01:01] <soren> Nafallo: On servers, though, we don't install it by default.
[01:03] <Nafallo> I know :-)
[03:23] <boxrock> can someone tell me how i play a wav file from shell? i get "oss_audio: failed to open audio device /dev/dsp" from flite
[03:29] <sommer>  boxrock: you can try aplay.  
[03:30] <sommer> comes with alsa-utils
[03:31] <boxrock> aplay x.wav => PULSEAUDIO: Unable to connect: Connection refused
[03:32] <sommer> is the module for your sound card loaded?
[03:33] <boxrock> i can play the wav file from GUI
[03:33] <boxrock> but i need CLI
[03:34] <sommer> mmmm...mplayer works from CLI.  Kind of a big package though.
[03:36] <baggito> mplayer is a good choice. it's quite robust
[03:36] <baggito> esdplay aswell, if you're using ESD
[03:36] <baggito> wait no. i'm talking crazy
[03:38] <baggito> yes it's in esound-clients package
[04:01] <lamont> soren: listening on 127.0.0.1 is allowed under the no-open-ports policyu
[04:01] <soren> lamont: Right.
[04:01] <soren> lamont: Have I said otherwise?
[04:16] <jdstrand> dendrobates: good morning
[04:16] <jdstrand> dendrobates: got your email about auth-client-config-- thanks
[04:16] <dendrobates> good morning
[04:17] <jdstrand> dendrobates: I also go the email about the change in the wiki.  notably:
[04:17] <jdstrand> wait a sec, I think I misread it
[04:18] <jdstrand> ok so no migration script?
[04:19] <dendrobates> no, in the interest of time
[04:20] <jdstrand> seems reasonable.  your assertion here may be over simplified:
[04:20] <jdstrand> If /etc/libnss-ldap.conf or /etc/pam_ldap.conf exist, notify user that he must manually migrate the files
[04:20] <dendrobates> feel free to modify it.
[04:21] <jdstrand> in the case that the libnss-ldap and libpam-ldap may not be purged
[04:21] <jdstrand> but removed
[04:21] <dendrobates> true.
[04:24] <jdstrand> will ldap-client-config depend, suggest, or recommend one or both of libpam-ldap and libnss-ldap?
[04:27] <dendrobates> I am working on  a dependency tree now.
[04:28] <jdstrand> ldap-client-config could conflict with a versioned libnss-ldap and libpam-ldap, then when libnss-ldap and libpam-ldap are upgraded, they can remove those conffiles
[04:29] <jdstrand> but then you'd need to be sure that they got upgraded before ldap-client-config
[04:30] <dendrobates> that will work if a user installs ldap-auth-client.  It will install everything.
[04:31] <dendrobates> But there are some complexities I am still learning.
[04:31] <jdstrand> right-- but on a standard upgrade, ldap-client-config wouldn't get installed yet
[04:32] <jdstrand> I am looking at this backward.
[04:32] <jdstrand> libnss-ldap must depend on ldap-client-config to have any configuration at all
[04:33] <jdstrand> libnss-ldap gets upgraded, and removes the old conffile
[04:33] <dendrobates> It does.
[04:33] <jdstrand> ldap-client-config create /etc/ldap.conf
[04:33] <jdstrand> ldap-client-config doesn't have to care at all about libnss-ldap.conf 
[04:34] <jdstrand> it could just warn the user that the confiles have moved around, if they are found
[04:34] <jdstrand> but the user is forced to use ldap-client-config to configure
[04:35] <dendrobates> yes.  I think it all works, but I need to look at all the use cases to make sure.
[04:36] <jdstrand> it does not provide a smooth upgrade though-- meaning pre-existing configuration is not preserved.  :(  But that was punted anyway
[04:36] <jdstrand> at least for gutsy
[04:36] <jdstrand> gutsy+1 is LTS?
[04:37] <dendrobates> yes.
[04:37] <jdstrand> so work could be done on the migration script for dapper to gutsy+1
[04:38] <dendrobates> I'm thinking of checking for the old conffiles at preinst, and kicking out before install so the user can fix it. What do you think?
[04:38] <dendrobates> yes on the dapper to gutsy+1
[04:39] <dendrobates> the problem is once the new pam_ldap and nss_ldap are installed there old confiles are useless and the system is broken.
[04:40] <jdstrand> to my thinking, if libnss-ldap and/or libpam-ldap are installed or removed but not purged, you will always hit that condition
[04:41] <jdstrand> on upgrade of course
[04:41] <dendrobates> true.  It will require user intervention.  Either migrate or purge than install.
[04:42] <dendrobates> brb
[04:42] <jdstrand> maybe for gutsy, an informational message stating the the conffile has moved to /etc/ldap.conf, but that it cannot be migrated and that they will be prompted for configuration via ldap-client-config
[04:43] <jdstrand> s/migrated/migrated automatically/
[04:45] <jdstrand> this would have to be done in both libnss-ldap and libpam-ldap
[04:45] <jdstrand> could also talk about the benefits of using a unified conffile, to make the pill go down easier.  :)
[04:46] <jdstrand> really-- since libnss-ldap and libpam-ldap will depend on ldap-config-config, you could put that message in ldap-client-config
[04:48] <jdstrand> as such, maybe rather than removing libnss-ldap.conf and pam-ldap.conf, those should be moved to libnss-ldap.conf.obsolete and pamldap.conf.obsolete, and the user told about that, so that the files are still available to compare with /etc/ldap.conf
[05:05] <dendrobates> jdstrand: are you talking about gutsy or gutsy +1
[05:05] <jdstrand> gutsy
[05:06] <jdstrand> gutsy+1 can keep working on migration script
[05:06] <jdstrand> for gutsy+1, only give message to user if the migration failed
[05:07] <jdstrand> these are ideas mind you.  but seems to work
[05:08] <jdstrand> to summarize my thoughts:
[05:08] <dendrobates> So you want to rename, and configure no matter what?
[05:08] <jdstrand> for gutsy-- yes, unless that migration script is ready
[05:10] <dendrobates> I see what you are saying, but I am not sure that pitti will be satisfied.
[05:10] <jdstrand> I don't find it particularly satisfying
[05:10] <jdstrand> :)
[05:11] <jdstrand> libnss-ldap and libpam-ldap *must* depend on ldap-client-config -- that is a given
[05:11] <dendrobates> I've already modied them to do that.
[05:12] <dendrobates> s/modied/modified/
[05:13] <jdstrand> problem is, on upgrade, without a migration script, I can't see how to do a smooth upgrade, unless you just pick one to copy over
[05:14] <jdstrand> perhaps that is a solution for gutsy.
[05:15] <jdstrand> message: I have detected libnss-ldap.conf.  This file is obsoleted by /etc/ldap.conf.  I can copy it over for you, or you can use ldap-client-config to create a new /etc/ldap.conf"
[05:16] <jdstrand> that is the gist, not the actual message
[05:17] <dendrobates> But what about pam_ldap.conf? Which do we use?  And we would also have to migrate the *.secret file if it exists. 
[05:17] <jdstrand> if both libnss-ldap.conf and pam-ldap.conf exist (highly possible with removed but not purged packages), you are in a bind though
[05:18] <dendrobates> That is the dilemma.  I wish we had more time to solve it, but we need to iron this out so it can get approved for gutsy.
[05:18] <jdstrand> why did you remove the checks for the .so files from the spec?
[05:19] <dendrobates> Because that is part of the migration, and I was deferring it.
[05:20] <jdstrand> deferring to what?
[05:20] <dendrobates> deferring it to gutsy+1
[05:20] <jdstrand> checking for the .so solves the purge/remove discrepency
[05:21] <jdstrand> if .so and conf, then cp
[05:21] <jdstrand> if !.so and conf, ignore
[05:21] <jdstrand> that could be optimized...
[05:22] <jdstrand> if .so, then cp
[05:22] <jdstrand> if !.so, then ignore
[05:22] <jdstrand> if libnss.so and libpam.so, then prompt for manual intervention
[05:22] <jdstrand> (don't know if those are the actual .so filenames off-hand)
[05:23] <jdstrand> but you get the idea
[05:23] <dendrobates> I agree with all that you are saying, but I want to get it approved in the simplified way, than if we have time to do a little scope creep before gutsy, fine.
[05:23] <eikke> grmbl
[05:24] <eikke> something's doing an invalid "GET /" request (no http version etc) on a regular base to my https server, request coming from localhost going to localhost
[05:24] <jdstrand> I agree with you too, I just don't think it can be done in a optimal way with conffiles alone
[05:24] <jdstrand> because of remove vs purge
[05:24] <eikke> every 10 minutes or so it does 2 consecutive requests, but I got no clue what causes this, and I hate that feeling
[05:25] <dendrobates> we can check  apt for the status of the packages.
[05:25] <jdstrand> in my experience (and this is esp true with ldap), many people try libpam-ldap and libnss-ldap (lots of different howtos and docs out there)
[05:26] <dendrobates> jdstrand: I have to meet some people for lunch.  Will you be around later?
[05:26] <jdstrand> yes-- after lunch for me too (EST)
[05:26] <dendrobates> ok later then.
[05:26] <eikke> ah, I just set up pam/nss-ldap today :)
[06:11] <lamont> ScottK: you wanna request the 2.4.5-1 sync:?
[06:15] <ivoks> 'evening
[06:16] <mathiaz> ivoks: hi
[06:17] <ivoks> i suggest closing bug 37027
[06:17] <ubotu> Launchpad bug 37027 in samba "Fails to install" [Medium,New]  https://launchpad.net/bugs/37027
[06:17] <ivoks> this must be product of some unsupported upgrade/install
[06:18] <ivoks> and it doesn't happen on dapper->edgy, edgy->feisty and feisty->gutsy
[06:19] <ivoks> even if it does happen on breezy, oh well, it isn't supported anymore :)
[06:20] <mathiaz> ivoks: it seems that someone was hit by the bug from dapper -> edgy
[06:20] <ivoks> i've tested that enviorment
[06:20] <ivoks> there is no sign of K09samba in /etc/rc*.d/
[06:21] <ivoks> that must've been some leftover from prerelease versions
[06:21] <ivoks> or product of some other package
[06:22] <mathiaz> ivoks: hum. There is a line "samba/generate_smbpasswd doesn't exist"
[06:23] <mathiaz> ivoks: in the output of one apt-get install
[06:23] <ivoks> and that's wierd too
[06:23] <ivoks> cause that exsist on dapper
[06:23] <ivoks> and all other versions
[06:24] <ivoks> take a look at
[06:24] <ivoks> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/45229/comments/1
[06:24] <ubotu> Launchpad bug 45229 in samba "dangling symlink: /etc/rc2.d/S91samba (dup-of: 37027)" [Medium,Confirmed]  
[06:24] <ubotu> Launchpad bug 37027 in samba "Fails to install" [Medium,New]  
[06:24] <ivoks> all reported in may
[06:24] <ivoks> we had no stable dapper release in may
[06:26] <infinity> ivoks: That bug's the product of some bizarre breakage in the gnome network applet, from eons ago.
[06:27] <infinity> ivoks: It keeps cropping up, though, which irks me, because I swear I can't find the offending code anywhere anymore.
[06:28] <ivoks> i belive you, cause i did almost 100 samba installations
[06:28] <ivoks> i've never seen this
[06:29] <ivoks> looking at changelog of sama
[06:29] <ivoks> you did an upload on may, 17.
[06:29] <ivoks> all bugs were repotred 17., 18. and 19.
[06:29] <ivoks> all but this one, which was 2006-03-28
[06:30] <ivoks> (take a look at duplicates of 37027)
[06:32] <ivoks> i would close it...
[06:33] <ivoks> we should have a resolution 'This is alien stuff'
[06:42] <ivoks> looking at the diff from earlier version, there isn't anything
[06:42] <ivoks> this isn't samba bug
[06:42] <ivoks> i'm sure.
[06:45] <ScottK> lamont: I'll take care of it.
[07:01] <lamont> ScottK: thanks.
[07:02] <ScottK> No problem.
[07:14] <ScottK> lamont: How you spend you time is your business, but in my experience trying to give Kmos help is an extremely unrewarding experience.
[07:18] <infinity> ScottK: But my debdiff was so CoC-friendly!
[07:18] <ScottK> I'm just saying.
[07:19] <infinity> Okay, had the changelog entry had s/\./, asshat./, it may have been better.
[07:19] <ScottK> I'd appreciate it if a core-dev would ack my Postfix sync bug to the archive.  Bug #130214
[07:19] <ubotu> Launchpad bug 130214 in postfix "Please sync postfix 2.4.5-1 from Debian Unstable (Main)" [Wishlist,New]  https://launchpad.net/bugs/130214
[07:19] <infinity> lamont: You aprove of the sync?
[07:19] <lamont> infinity: yep
[07:19] <infinity> lamont: If so, I'll sync it right now.
[07:19] <lamont> it supersedes the ubuntu fixes
[07:19] <ScottK> Cool.
[07:20] <lamont> which ScottK did and I merged.
[07:20] <lamont> ScottK: debian package, in git on an ubuntu machine... it's all good.
[07:21] <ScottK> Even better.
[07:21] <ScottK> I liked that part of debian/changelog too.
[07:21] <lamont> there was a DD who didn't really like it, pointed out that git.debian.org exists
[07:22] <ScottK> And why should a DD be upset if Canonical is paying for the web space to host a Debian package?
[07:23] <infinity> ScottK: Done.
[07:23] <ScottK> BTW, my only solution so far to the personality we were discussing earlier is to just stay off channels he's active on.
[07:23] <ScottK> infinity: Cool.  Thanks.
[07:23] <LiENUS> on a fresh LAMP install how to i use mysql?
[07:24] <lamont> infinity: thanks
[07:24] <lamont> ScottK: I refuse to let someone else determine what channels I don't visit.
[07:24] <infinity> lamont: Don't visit this one ever again.
[07:24] <infinity> (And I could totally back that up if I knew who owned it..)
[07:24] <lamont> :-P
[07:25] <ScottK> In general, I agree, but in his case he does so much damage, it gets me so upset, it's not good for me or Ubuntu.
[07:25] <infinity> Oh, FFS, we never registered it.  It has no owner.
[07:25] <lamont> infinity: fix that or I will
[07:25] <lamont> oh, and op me. :-0
[07:25] <lamont> :-*
[07:25] <ScottK> I've already been way far on the wrong side of CoC for the first time since I've been here.
[07:28] <soren> infinity: Which channel has no owner?
[07:28] <soren> infinity: This one? #u-d?
[07:28] <infinity> Oh, wait, no, it's registered, I'm a muppet.
[07:28] <soren> infinity: thom owns #u-d.
[07:28] <soren> someone named troy owns this one.
[07:28] <soren> No idea who he is.
[07:28] <ScottK> Yes, but your a muppet that sync'ed Postfix, so I'm happy.
[07:28] <infinity> Yeah, I noticed.
[07:29] <infinity> soren: Are you contacting him?  (I was about to, but don't want to flood him with messages)
[07:30] <lamont> ScottK: infinity is _MY_ muppet, that makes him cool. :-)
[07:30] <ScottK> Heh.
[07:30] <ScottK> Well that's the first time I think I've gotten a new bug and fix released in the same bugmail.
[07:31] <infinity> soren: Getting it fixed now.
[07:32] <infinity> soren: I'll op you, lamont, and mathiaz when I take ownership.  Deal?
[07:32] <infinity> Oh, and thom.  Cause thom is love.  Even if he's not idling here right now.
[07:33] <lamont> infinity: sounds good.  thom is love
[07:33] <lamont> remember to give him hugs and beer
[07:33] <infinity> I always try to.
[07:33] <infinity> He didn't visit me when I was in London, though. :(
[07:33] <infinity> Some wishy-washy excuse about his wallet disagreeing with the airfare.
[07:35] <ScottK> Time to go file my launchpad bug of the day.
[07:36] <ScottK> lamont: When you leave the LP bug numbers in the debian/changelof for a sync, even though those bugs are already fixed, LP sends Fix Release bugmail again.
[07:36] <ompaul> infinity, you have a pm
[07:36] <ScottK> Just so you know.
[07:36] <lamont> ScottK: kewl. :-)
[07:36] <infinity> ompaul: Noticed. :)
[07:37] <ompaul> infinity, pas de problem I'm now history ;-)
[07:37] <ScottK> My theory in LP is that since it's proprietary, I can fix stuff, so the least I can do is complain a lot.
[07:37] <ScottK> can/can't.  Oops
[07:39] <soren> infinity: cool. I haven't done anything about it yet.
[07:43] <soren> w00t
[07:53] <soren> ScottK: :)
[07:55] <infinity> soren: It's considered rude to idle with +o on a ChanServ-controlled channel. :)
[07:56] <soren> infinity: Really? But it looks so shiny!
[07:57] <soren> Oh, well.
[07:58] <infinity> This ain't EFnet, we'll have no cowboy ops here!
[07:59] <infinity> Though I do rather like how I managed a channel takeover without a single bit of investigation on the part of the freenode staffer.
[07:59] <infinity> Makes me feel all warm and fuzzy.
[08:02] <lamont> infinity: remember, we can only use our superpowers for good.
[08:02] <infinity> But it's so tempting...
[08:02] <lamont> ln: creating symbolic link `/home/lamont/gutsy/linux-source-2.6.22-2.6.22/debian/linux-headers-2.6.22-9-hppa32/usr/src/linux-headers-2.6.22-9-hppa32/./.' to `linux-headers-2.6.22-9/.': File exists
[08:02] <lamont> GAH
[08:03] <infinity> LAMONT IS A KERNAL NOOB LOL!!!111ONE
[08:03] <lamont> infinity: I'm trying to not clean the tree between builds, that's all
[08:04] <lamont> and the kernel build uh, stuff, isn't cooperating
[08:04] <infinity> Clearly, the rules file needs a "kinda-clean" target.
[08:04] <infinity> debian/rules tidy
[08:04] <lamont> binary-clean
[08:04] <lamont> or a -f on that ln -s... :-)
[08:05] <infinity> I think I'm going to phone HP and tell them that you're not l33t enough for your job.
[08:05] <infinity> Is there a hotline for that sort of thing?
[08:06] <lamont> 1 800 EAT .....
[08:06] <infinity> My phone doesn't have a "." key.
[08:06] <infinity> Damnit.
[08:07] <lamont> or was it 2?>
[08:07] <infinity> Actually, the 1 key 3 times is "..."   Predictive text, FTW.
[08:07] <lamont> and a 4th time?
[08:08] <infinity> Another ., apparently.
[08:09] <infinity> But 5 in a row gives me "...:)"
[08:09] <infinity> Sony, you never cease to amaze and amuse.
[08:13] <soren> lamont: You want to look in debian/stamps or something.
[08:13] <soren> lamont: If you remove the right one, the kernel build system will dtrt and only rebuild what is necessary.
[08:13] <infinity> soren: No, he wants to not be a muppet that rebuilds the hppa kernel 38 times a day.
[08:13] <soren> infinity: True that.