[12:07] <Keybuk> he'd already tried that
[12:07] <Keybuk> seems to be an output plugin problem
[12:07] <Keybuk> set to ximagesink it's fine, xvimagesink isn't
[12:08] <slomo_> no idea then :(
[12:12] <Riddell> hi hub, did you get sorted?
[12:13] <hub> Riddell: my upgrade?
[12:13] <hub> Riddell: yeah it sort of work
[12:14] <Riddell> hub: what was up with X?
[12:14] <hub> mkfontdir
[12:14] <hub> as hinted by slomo_ 
[12:15] <hub> I still have a couple of issues like Perl disliking the locale and an artsmessage poping up
[12:15] <hub> (KDE)
[12:16] <neom> Hub. :o)
[12:16] <slomo_> hub: you use kde?
[12:18] <hub> slomo_: it depends of the machine
[12:18] <hub> slomo_: that machine has Kubuntu Dapper upgraded to edgy
[12:18] <hub> the laptop is still Gnome + KDE apps
[12:19] <hub> other work machine run another distro for dogfooding
[12:19] <slomo_> hub: oh, i expected you beeing a pure gnome guy :)
[12:19] <hub> slomo_: i'm not pure
[12:20] <neom> Linus said gnome sucks. :o
[12:20] <hub> even more given my paycheck
[12:20] <hub> neom: who cares
[12:20] <neom> linus, apparently. 
[12:23] <Keybuk> frankly, who'd go to a kernel engineer to write a desktop environment?  words like "usability" just aren't in their dictionary
[12:25] <Riddell> "Gnome + KDE apps" sounds like the edubuntu approach :)
[12:27] <hub> Riddell: or some other people. I just migrated to KMail
[12:27] <hub> even if it annoys me sometime
[12:27] <hub> it just provide better feature than Evo and T-bird
[12:28] <Riddell> what feature won you over?
[12:29] <LaserJock> Riddell: well, it's hard to overcome kalzium ;-)
[12:29] <hub> apply filter manual that t-bird do not do
[12:29] <hub> and keyboard navigation that evo do not to
[12:29] <hub> and the  bloat as is missing ;-)
[12:29] <Riddell> right
[12:30] <hub> some bugs or missing things though
[12:30] <hub> like the notification icon that bugs with gnome-panel
[12:30] <Riddell> I just use mutt, but people say that KMail has good features. Until they find it deleting their inbox
[12:30] <hub> Riddell: I use IMAP over several accounts
[12:31] <hub> Riddell: that's why I stopped using mutt
[12:31] <hub> still love it
[12:33] <johanbr> I tried KDE for a while, before switching back to Gnome. KMail played a large part in making me switch back, with the weird contortions you have to go through just to get KMail to read a spool file filtered by procmail.
[12:33] <hub> Riddell: the worse is that $COMPANY will want us to move to use Evolution on top of our KDE desktop because of the groupware solution
[12:34] <Burgwork> hub, you telling me Xandros uses exchange?
[12:35] <Riddell> hub: really?  but KMail has pretty decent groupware support, what's the server that's needed?
[12:35] <hub> Burgwork: no. Scalix
[12:35] <hub> Burgwork: we ship it
[12:35] <Burgwork> ah
[12:35] <hub> Riddell: Scalix
[12:36] <hub> Burgwork: between you and me, I wouldn't have been surprised to see exchange coming at one point
[12:36] <Burgwork> ugh, you poor man
[12:36] <hub> Burgwork: but at least it is the product we ship with out server solution
[12:36] <hub> I'll see. If I lose server side filtering, I'm not gonna be happy
[12:38] <bluefoxicy> anyone know if I should have a file '/etc/ld.so.conf.d/$machine-$os' ?
[12:39] <hub> Burgwork: at my previous company they wanted to sell and ActiveX based webmail solution
[12:39] <slomo_> bluefoxicy: yes, should be there
[12:39] <hub> Burgwork: with all the engineering running Linux
[12:39] <bluefoxicy> slomo_:  should it have dollar signs in the file name?
[12:39] <bluefoxicy> that's a really strange name for a file o.o
[12:39] <hub> Burgwork: like there were using Flash at one point for engineering tools....
[12:40] <zul> hey
[12:41] <Kamion> libc6: /etc/ld.so.conf.d/$machine-$os
[12:41] <Kamion> bluefoxicy: ^-- look for bugs filed there, I guess
[12:44] <bluefoxicy> nope, seeing no bugs filed. slomo_, Kamion:  So I'm guessing $machine and $os WERE supposed to expand to something?  (i386-pc and gnu-linux probably)  Or should I not file a bug?
[12:45] <Keybuk> powerpc-unknown-linux-gnu ?
[12:46] <bluefoxicy> Keybuk: powerpc-overheating-linux-gnu if you have a Macbook Pro
[12:46] <Kamion> bluefoxicy: file the bug, I'm sure it's something obvious in the glibc build system
[12:46] <bluefoxicy> kay.
[12:46] <Kamion> and yes it's powerpc-unknown-linux-gnu
[12:46] <Kamion> (or so saith config.guess)
[12:49] <bluefoxicy> bug filed.
[12:49] <Kamion> ta
[01:09] <zul> gah i suck at documentation
[01:19] <ehazlett> hey all...  im trying to install software in a chroot env via python.  i keep getting dpkg exiting with errors, but installs find when i manually chroot... any ideas?
[01:20] <sladen> ehazlett: pbuilder maybe what you're after?
[01:20] <ehazlett> im not sure...  i am trying to use   chroot <root> apt-get install packageA
[01:21] <ehazlett> i dont want to build a .deb, i want to install via apt
[01:24] <johanbr> ehazlett: Some python component that's not in the chroot, maybe?
[01:27] <ehazlett> could be... although everything works fine if i just chroot from the shell.  when i try it from python, i get E: Sub-process /usr/bin/dpkg exited unexpectedly for every package...
[01:33] <infinity> ehazlett: environment breakage?  Lack of a controlling TTY?
[01:36] <ehazlett> infinity: maybe.  any ideas for fix?  would that error happen if there was no console to output to?
[01:37] <infinity> ehazlett: I'd need more to go by than just that error.
[01:38] <ehazlett> ok. here's what im doing.  i have a selection of packages in a pygtk gui.  once selected, i chroot into the environment (which is the ubuntu live cd) and do apt-get install
[01:39] <ehazlett> i mount /proc and copy dns info.  the debs are there in the cache, but i can't get them to go...
[01:42] <ehazlett> i know ubuntu doesn't need another customization kit, but i started this project to learn pygtk, and decided to finish it... ive got it done except for this stage...  any help would be much appreciated... :)
[03:44] <bddebian> Hello
[03:45] <Hobbsee> hi bddebian 
[03:48] <bddebian> Hi Hobbsee
[03:49] <Hobbsee> has anyone done the mesa updates, and lived to tell the tale?
[03:50] <crimsun> what do you mean by 'done'?
[03:51] <rodarvus> Hobbsee, me :)
[03:51] <Hobbsee> crimsun: sorry, done as in upgraded
[03:51] <rodarvus> twice today :D
[03:51] <Hobbsee> rodarvus: did you break anything?
[03:51] <rodarvus> but I packaged mesa, so I might be biased :P
[03:52] <rodarvus> Hobbsee, X (and Mesa) has no bugs
[03:52] <rodarvus> it always the kernel, Gnome, KDE or some other package
[03:52] <rodarvus> its
[03:52] <Hobbsee> rodarvus: rofl!  right.
[03:52] <Hobbsee> rodarvus: sure sure.
[03:52] <Hobbsee> rodarvus: then surely you should fix all those bugs then too :P
[03:53] <zul> rodarvus: yay blame us ;)
[03:53] <rodarvus> I would fix X bugs if there were any
[03:53] <bddebian> sweet
[03:54] <rodarvus> Hobbsee, btw, if you wait for another hour or so, another (better) mesa update is already underway
[03:54] <rodarvus> so, don't waste your bandwidth with this update
[03:54] <rodarvus> (now, I mean)
[03:54] <Hobbsee> rodarvus: but whyever would you need one?  you just said it contained no bugs, so therefore should need no fixing?
[03:54] <Hobbsee> :P
[03:54] <rodarvus> its not bugfixing
[03:55] <rodarvus> its a new upstream release (Mesa 6.5)
[03:55] <mjg59> AlinuxOS: I've just uploaded a new ttf-bpg-georgian-fonts to Debian
[03:55] <rodarvus> needed for X.Org 7.1
[03:55] <Hobbsee> ooh...fun :)
[03:55] <mjg59> AlinuxOS: I'll get it synced over to Ubuntu once it's in the archive
[03:55] <Hobbsee> when's xorg 7.1 coming in?
[03:55] <johanbr> rodarvus: Have you seen the bug where emacs, xfontsel, among other programs, claim there are no fonts present?
[03:55] <mjg59> rodarvus: Score
[03:56] <rodarvus> Hobsee: a very large part of it is already installed on your machine, if you have edgy
[03:56] <mjg59> rodarvus: Are you going to build with aiglx by default?
[03:56] <Hobbsee> rodarvus: nick completion is good, and okay.
[03:56] <mjg59> (Even if you do, I believe it's disabled unless the user enables it in xorg.conf)
[03:56] <rodarvus> mjg59, not right now (it wasn't specced), but I plan to, if time allows
[03:56] <rodarvus> not sure if its going to happen for Edgy, though
[03:56] <rodarvus> (I'd really like to, if possible)
[03:57] <Hobbsee> rodarvus: just dont eat or sleep, you'll be fine :P
[03:57] <mjg59> rodarvus: Ok. I'll look into what's needed
[03:57] <rodarvus> mjg59, thanks - really appreciated!
[03:57] <mjg59> rodarvus: If all else fails, and the build-depends are there, I'll just update the source package in universe
[03:57] <rodarvus> build-deps are supposed to be there
[03:58] <ajmitch> wonderful
[03:58] <ajmitch> more shiny stuff
[03:58] <mjg59> rodarvus: Yeah, mesa was the main sticking point
[03:58] <ajmitch> mjg59: do you plan to update the xgl package, or should we do it (before the horde of users comes down on us)?
[03:59] <mjg59> ajmitch: Is Xgl in the main xorg tree yet?
[03:59] <bddebian> Are we still not including GLw libs?
[03:59] <ajmitch> probably not
[03:59] <ajmitch> I haven't checked lately
[03:59] <rodarvus> bddebian, yes, we are not including GLw
[03:59] <mjg59> If not, just greab the source package, do cvs update and make it use the new mesa
[03:59] <rodarvus> we have a policy of not supporting motif/lesstif on main
[03:59] <bddebian> rodarvus: Great, since I removed them from grass.  Thanks :-)
[04:01] <mjg59> Then someone needs to sort compiz
[04:02] <ajmitch> that could be thorny
[04:02] <rodarvus> I still have about 50 drivers I want sorted out before even thinking of any other package :/
[04:03] <Hobbsee> rodarvus: where are you?  isnt it 3 am or something there?
[04:03] <ajmitch> go with upstream, or go with the fork on compiz.net?
[04:03] <crimsun> 11:03 P.M.
[04:03] <rodarvus> Hobbsee, no, its 11 PM here
[04:03] <rodarvus> (UTC-3)
[04:03] <Hobbsee> rodarvus: ah ok, US somewhere.  i thoguht you were in europe
[04:03] <rodarvus> actually, Brazil somewhere :)
[04:04] <Hobbsee> rodarvus: ahhh...nice!  :)
[04:04] <mjg59> ajmitch: I don't care, as long as we don't ship with the Novell logos...
[04:04] <mjg59> ("oops")
[04:04] <bddebian> heh
[04:04] <Hobbsee> hehe
[04:04] <Hobbsee> please tell me we didnt do that.
[04:05] <ajmitch> nice, cvs update, half the makefiles conflict
[04:05] <ajmitch> do I care enough to fix it?
[04:06] <Hobbsee> ajmitch: yes, you do.
[04:06] <mjg59> Hobbsee: Nope
[04:06] <mjg59> ajmitch: For xgl?
[04:06] <ajmitch> yes
[04:06] <mjg59> Makefiles, or Makefile.am?
[04:06] <mjg59> (or Makefile.in, etc)
[04:06] <ajmitch> Makefile.am
[04:06] <mjg59> Oh, that's a bit of an arse
[04:07] <ajmitch> all in the GL dir
[04:07] <mjg59> Oh, hrm. I may have done horrible sed shit all over them at some stage
[04:07] <mjg59> Ah, right
[04:07] <ajmitch> so it may not matter
[04:07] <mjg59> Just nuke them and pull the upstream ones
[04:07] <mjg59> The changes shouldn't be needed with new mesa
[04:07] <ajmitch> going back to cvs after using bzr is an experience
[04:08] <mjg59> Yeah, it's like having a leg cut off
[04:08] <mjg59> You want to roll back one changeset, but...
[04:09] <ajmitch> right, seems to be in order now
[04:11] <mjg59> Cool
[04:12] <ajmitch> I really shouldn't do this on the laptop, it's got a much slower disk for building
[04:12] <mjg59> Haha
[04:12] <Hobbsee> hehe
[04:12] <mjg59> Wow
[04:12] <mjg59> That's a point
[04:12] <mjg59> I don't have a single machine with a 3.5" drive
[04:12] <mjg59> Except the TV
[04:13] <rodarvus> ajmitch, mjg59: if you plan on build anything Mesa-6.5-dependant right now, please wait another hour or so (an even newer version of mesa was uploaded 1.5 hours ago)
[04:15] <mjg59> Doing dist-upgrades at night is noticably faster
[04:15] <ajmitch> rodarvus: I can wait, I've got far more important things to do :)
[04:15] <mjg59> Wow.
[04:16] <mjg59> I've finally found time to do Debian maintenance, and I suddenly feel so much better
[04:16] <zul> got the monkey off your back?
[04:17] <LaserJock> mjg59: did Ubuntu on intel macs sort of die out? I was looking around on the web and most of the stuff is a few months old
[04:18] <mjg59> LaserJock: Erm.
[04:18] <mjg59> LaserJock: Dapper should pretty much just work
[04:18] <mjg59> Only problem is that you have to do the partitioning under MacOS
[04:19] <LaserJock> mjg59: how do you boot it. I've seen bootcamp + rEFit + lilo
[04:20] <mjg59> Skip the refit stage, just use lilo
[04:20] <mjg59> Holding down alt lets you choose
[04:20] <LaserJock> ok, so use bootcamp to set stuff up, boot up an Ubuntu cd and use lilo?
[04:20] <mjg59> Yeah
[04:21] <bddebian> Do the Smashintels use OpenFirmware?
[04:21] <LaserJock> hmm
[04:21] <mjg59> I'll try to sort out parted in time for edgy
[04:21] <mjg59> At the moment it's irritatingly spec-compliant, which isn't what you want here
[04:21] <mjg59> And a small patch for grub, then everything'll be fine
[04:22] <zul> mjg59: debian already has the patch for macintel which got synced for edgy
[04:22] <mjg59> In grub? Cool.
[04:22] <zul> yep
[04:25] <vignatti_> Greetings
[04:25] <mjg59> So just parted to "fix"
[04:26] <vignatti_> What is the name of the disk partition on ubuntu?
[04:26] <Hobbsee> mjg59: hah.  love your reply w.r.t. suspend2 on ubuntu-devel mailing list :P
[04:31] <jsgotangco> heh
[04:32] <bddebian> Heya jsgotangco
[04:41] <bddebian> Someone please kill me
[04:42] <bddebian> Ah, LaserJock will do it
[04:42] <LaserJock> mjg59: do I want to create a Drivers CD in bootcamp or is that only for Windows?
[04:43] <LaserJock> bddebian: I'll do what?
[04:44] <bddebian> LaserJock: Kill me
[04:44] <LaserJock> oh, sure, no problem ;-)
[04:44] <bddebian> Fire up one of your lasers and saw me in half
[04:44] <mjg59> LaserJock: Just for Windows
[04:44] <LaserJock> unfortunately none of mine will saw people in half
[04:44] <bddebian> Or better yet, burn my eyes out so I don't see axiom anymore
[04:44] <zul> night
[04:44] <bddebian> Gnight zul
[04:45] <LaserJock> however, I think the mechanical engineering dept. has one
[04:45] <LaserJock> cya zul 
[05:50] <LaserJock> mjg59: still around?
[07:13] <dieman> nice. digg effect on wiki.ubuntu.com
[07:22] <pitti> Good morning
[07:22] <Hobbsee> hi pitti 
[07:22] <Vhata> Some mornings, it's just not worth chewing through the leather straps.
[07:23] <pitti> hi Hobbsee 
[07:49] <pitti> rodarvus: btw, urgency field does not matter at all for Ubungu
[07:49] <pitti> rodarvus: Ubuntu, too
[07:54] <Vhata> why does edgy tell me I have 0 packages upgraded, 1 newly installed, 79 to remove and 3 not upgraded.
[07:55] <Vhata> I'm okay with it removing nano, but not postfix etc.
[07:55] <Hobbsee> Vhata: cos you're system's in serious trouble?
[07:55] <Vhata> that's the first install I do after install ubuntu-standard
[07:55] <Hobbsee> what's the one newly installed one?
[07:55] <Vhata> Hobbsee: that was me about to install joe
[07:56] <Vhata> I haven't actually done anything serious to put my system into trouble... except a dpkg-reconfigure -a ?
[07:57] <Vhata> this is what I get for installing joe.
[08:00] <Hobbsee> likely
[08:00] <Hobbsee> if it hasnt been updated
[08:07] <pitti> Kamion: tasksel approved; will this be used in the first-stage installer, or only in the installed system? in the former case, I should add it to the striptranslations blacklist
[08:09] <dieman> wow, thats cute.
[08:10] <dieman> if your background image is missing and it shows back up, i guess nautilus gets an notification and updates the background
[08:47] <bluefoxicy> sweet.
[08:47] <bluefoxicy> I reduced gettimeofday() calls on an order of 500 times.
[08:47] <bluefoxicy> now all I need is something faster than gettimeofday() (I used posix timers to do interval timing, except it's about 25-50% slower than gettimeofday())
[08:47] <bluefoxicy> the code handles skew to a configurable accuracy with automated drift checking on a sliding window; but it's pretty useless without some method that's faster than gettimeofday() to replace it with.
[08:59] <lifeless> bluefoxicy: what ya working on?
[08:59] <bluefoxicy> lifeless: http://lwn.net/Articles/192214/  "X is a big offender, apparently because the gettimeofday() call is still too slow and maintaining time stamps with interval timers is faster."
[09:00] <bluefoxicy> lifeless:  I'm trying to maintain timestamps on a gettimeofday() type interface, in the background, automatically
[09:01] <bluefoxicy> pretty much I initialize a timer to gettimeofday() and set up a posix timer that's set to 999999999 usecs (1 second - 1 microsecond), and then when asked the time of day check the posix timer.
[09:01] <bluefoxicy> if it's disarmed (i.e. time ran down), I use gettimeofday()
[09:01] <bluefoxicy> if it's armed, I add the amount of time that's passed on the timer to my stored timeval; incriment a 'drift' on my timer; and copy my timeval into the target
[09:02] <bluefoxicy> If my 'drift' reaches a 'dcheck' value, I check for drift and reinitialize from gettimeofday(); if there is drift (i.e. I'm more than (accuracy) off from gettimeofday()), I decrease 'dcheck' so that drift is checked for more often (more gettimeofday() usage)
[09:03] <bluefoxicy> if there's no drift and I'm less than 95% of (accuracy) away from gettimeofday(), I increase 'dcheck' to lower the amount of gettimeofday() usage
[09:04] <bluefoxicy> lifeless:  the result is that I'm using a target accuracy of 500uS, so I'm probably within 1000uS (actually within 550uS), and using gettimeofday() 1/500 of the time.
[09:04] <bluefoxicy> the problem is, of course, that checking the time left on posix timers is SLOWER than gettimeofday()
[09:04] <bluefoxicy> so I'm trying to figure out what this magical "interval timers" thing is.
[09:05] <lifeless> bluefoxicy: ah
[09:05] <bluefoxicy> I asked davey jones
[09:06] <bluefoxicy> since he gave the original "userspace is way too slow" speech.
[09:06] <lifeless> setitimer ?
[09:06] <lifeless> http://www.quepublishing.com/articles/article.asp?p=23618&seqNum=14&rl=1
[09:07] <bluefoxicy> ah
[09:08] <lifeless> (btw, 'linux interval timer' in google :))
[09:09] <bluefoxicy> hah
[09:09] <bluefoxicy> the thing with that is it's signal based, so I can't turn it into a black box
[09:09] <bluefoxicy> plus there's only 3 interval timers, and I need the realtime one.
[09:10] <bluefoxicy> so it's not a case of "stick it there, use the interface, it works;" more "don't use this that and the other thing, and this will work"
[09:10] <bluefoxicy> so much for being generic.
[09:10] <lifeless> well
[09:10] <lifeless> I think the point is that if gettimeofday could be made faster the kernel folk would
[09:11] <lifeless> so, its about doing things differently in the user app
[09:11] <Amaranth> bluefoxicy: is what you already have better than what X does?
[09:12] <bluefoxicy> Amaranth:  it's slower by 30% because timer_settime() is slower than gettimeofday()
[09:12] <desrt> does anyone have a copy of dave jones' slides from ols?
[09:12] <desrt> sounds like they might be a good read
[09:12] <Amaranth> bluefoxicy: err, i thought you were using gettimeofday() and a timer
[09:13] <bluefoxicy> Amaranth:  I want to avoid anything that delivers random signals or spawns threads (I can get the timers to spawn threads to update but then i have to worry about thread safety and such)
[09:13] <Amaranth> oh
[09:13] <Amaranth> i see
[09:13] <Amaranth> so you made something much more complex yet slower than just using gettimeofday() directly :)
[09:13] <bluefoxicy> yeah
[09:15] <desrt> heh
[09:17] <Vhata> is there a better way of doing this?  dpkg-query -W -f '${Package}\n' | xargs debsums -c
[09:17] <bluefoxicy> I'm going to sleep.
[09:18] <desrt> Vhata; some sort of tripwire setup?
[09:18] <Vhata> desrt: that sort of thing, yeah
[09:18] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/timer/ if anyone wants to toy with this junk.
[09:19] <Vhata> err, debsums probably won't tell me if a package was badly installed, will it?
[09:23] <dholbach> good morning
[09:24] <desrt> dholbach; word.
[09:25] <seb128> hey dholbach desrt
[09:25] <desrt> dholbach; your ubuntu laptop badges are making the rounds in canada.  mad props.
[09:25] <dholbach> yo desrt
[09:26] <dholbach> desrt: coool :-)))
[09:26] <desrt> oh.  i wanted to upload a picture.
[09:26] <desrt> action shot.
[09:29] <desrt> http://desrt.mcmaster.ca/random/dholbach-in-action.jpeg
[09:29] <ajmitch> impressive
[09:30] <desrt> thx
[09:30] <desrt> took me a few tries to get one right on the paddle like that :)
[09:30] <dholbach> hahahaha :)
[09:30] <dholbach> that was really nice
[09:31] <Gloubiboulga> hello
[09:42] <imbrandon> moins fellas
[09:44] <Fujitsu> Morning, imbrandon.
[09:46] <desrt> seb128; good day.
[09:47] <seb128> hi desrt
[09:47] <desrt> what's up on the crazy continent?
[09:47] <Hobbsee> desrt: it's now painted purple/
[09:47] <desrt> that's awesome!
[09:48] <desrt> those crazy europeans... always doin' something new
[09:48] <desrt> seb128; where do you live?
[09:49] <seb128> desrt: France
[09:49] <desrt> thanks, tips
[09:49] <desrt> but seriously.. where
[09:50] <seb128> seriously? France :p
[09:50] <Vhata> seb128: that's near Kenya, yes?
[09:50] <seb128> North-East
[09:50] <seb128> near of Germany
[09:50] <desrt> near lux?
[09:50] <desrt> or more east of there?
[09:51] <dholbach> near lux too
[09:51] <seb128> desrt: near of Luxembourg and near of Germany
[09:52] <seb128> like in the north-east corner near of them
[09:52] <seb128> oh?
[09:52] <seb128> anything interesting to do there? :)
[09:52] <desrt> look at the pretty things, i guess
[09:53] <desrt> and probably spend an awful lot of cash
[09:53] <desrt> i understand it's an expensive place to be
[09:54] <seb128> desrt: yeah, luxembourg is sort of expensive ... because they sort of have some money to spend :)
[09:55] <hungerW> seb128: And they do not even have to spend as much on fuel as i.e. germans:-)
[09:55] <desrt> hungerW; s/ie/eg/
[09:55] <hungerW> desrt: What does eg stand for?
[09:55] <desrt> for example
[09:56] <hungerW> desrt: Man, your spelling sucks;-)
[09:56] <hungerW> desrt: There is no e in for and no g in example;-)
[09:56] <desrt> egsample
[09:57] <hungerW> desrt: A sample of an egg?
[09:57] <neuralis> hungerW: exempli gratia
[09:57] <hungerW> neuralis: Ahhh, thanks.
[09:57] <hungerW> neuralis: Now I have a fighting chance to remember e.g.;-)
[09:57] <neuralis> np
[09:58] <seb128> desrt: is there an easy way to know if gnome-vfs is using inotify or gam,fam?
[10:00] <desrt> seb128; it's using inotify
[10:00] <desrt> :)
[10:01] <desrt> seb128; or is this more like you have to tell something to someone on bugzilla to figure out what the heck is going on?
[10:01] <seb128> desrt: not, that's like I've gam_server running
[10:01] <desrt> in that case check if fam or gamserver is running
[10:01] <desrt> o.
[10:01] <seb128> and after sending it a SIGUSR2 the log has things like
[10:01] <seb128> "if that's what you want to ask, what about asking dir"
[10:01] <seb128> ups
[10:01] <seb128> stupid copy being b0rked
[10:01] <desrt> that's an odd log message :)
[10:01] <seb128> "MONDIR request: from nautilus, seq 3, type 2 options 0
[10:01] <seb128> nautilus listening for"
[10:02] <seb128> to /tmp/gamin_debug_QX9zWH
[10:02] <seb128> and directories like ~/Templates being listed there
[10:02] <desrt> have you messed around with your kernel and disabled inotify or something?
[10:02] <seb128> no
[10:02] <seb128> but maybe the edgy kernel is b0rked
[10:02] <seb128> that's why I'm asking how I can know if it's using inotify or not :)
[10:02] <desrt> gnome-vfs will check for inotify and fall back on libfam
[10:03] <seb128> right, that I know
[10:03] <dholbach> idiotify! :-)
[10:03] <desrt> well.  it is clearly using fam :)
[10:03] <seb128> the question is "how do I make it tell what he figured about inotify"
[10:03] <seb128> s/he/it
[10:03] <desrt> strace gnomevfs-monitor ~
[10:03] <desrt> SYS_291(0xb7fbfb30, 0xb7fb15e0, 0x1, 0xb7fb134c, 0xb7f3ce60) = 9
[10:03] <desrt> ^ inotify
[10:04] <seb128> SYS_291(0xb7fd1c70, 0, 0x1, 0xb7fbd7c0, 0xb7f537d0) = 3
[10:04] <desrt> i wonder where all my fds went
[10:05] <desrt> holy crap gam_server is running
[10:05] <seb128> :)
[10:05] <desrt> wtf!
[10:05] <Amaranth> i knew something was wrong :P
[10:05] <seb128> desrt: ok, that's where I wanted to bring you ;)
[10:06] <seb128> so either linux is b0rked
[10:06] <seb128> or gnomevfs is
[10:06] <Amaranth> need a small app that using inotify directly
[10:07] <dholbach> i think mvo wrote a piece of code that does that.
[10:08] <dholbach> but he's not here yet
[10:08] <desrt> it's clearly using inotify directly
[10:08] <seb128> dholbach: inotify upstream has some code for that, why is mvo reinventing the wheel :)
[10:08] <ogra> there must be an old inotify bug where he attached it
[10:08] <desrt> pipe([3, 4] )                            = 0
[10:08] <desrt> pipe([5, 6] )                            = 0
[10:08] <desrt> pipe([7, 8] )                            = 0
[10:08] <dholbach> seb128: he wanted to play with it
[10:08] <desrt> in the middle of nowhere
[10:09] <seb128> dholbach: right, that's mvo :p
[10:09] <desrt> oh.  seb.  do you have very new gnomevfs installed?
[10:09] <desrt> orbit seems to be making these pipes -- a problem that very new gnome-vfs would not have :)
[10:10] <seb128> desrt: I've edgy, which has 2.15.90 from yesterday
[10:10] <seb128> or from monday :)
[10:10] <desrt> there's a very unhappy darwin user on gnome buzilla
[10:10] <seb128> dholbach: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils/inotify-utils-0.25.tar.gz
[10:10] <desrt> the whole "just move the symbols from libgnomevfs to libbonobo" thing doesn't work on macos :)
[10:10] <seb128> desrt: cf ABI breakage and wanting to bump the soname?
[10:10] <ajmitch> right. xgl updated from git, but will it work?
[10:10] <desrt> ya.  jerk.
[10:11] <seb128> desrt: I don't like his tone
[10:11] <seb128> "Perhaps you need to go and reread the library versioning section of the libtool
[10:11] <seb128> manual (assuming you read it in the first place)"
[10:11] <desrt> seb128; i sort of like christian/alex's tones... but for a bad reason :)
[10:11] <seb128> LART
[10:11] <seb128> hehe
[10:11] <desrt> the gnome community is increasingly getting the "if it's not linux, i don't care" attitude
[10:11] <desrt> which i think is really good
[10:12] <Amaranth> inotify-test seems to be working
[10:12] <desrt> inotify is definitely working.  those syscalls are returning good things.
[10:12] <Amaranth> so i'm thinking something is wrong with gnome-vfs
[10:12] <seb128> in fact the gam_server log I've about nautilus seems to be for non-existant directories it has to monitor
[10:12] <desrt> fwiw, i'm using straight inotify here with no gamin
[10:12] <desrt> i have no idea why gam_server is running
[10:12] <seb128> like I had no ~/Templates
[10:12] <seb128> so inotify seems to complain and it falls back using gam_server for polling it
[10:12] <seb128> or something like that
[10:13] <Amaranth> hrm
[10:13] <seb128> $ tail -f gamin_debug_XYpe57
[10:13] <seb128> Event to /usr/bin/epiphany : 1, 2, /usr/local/share/applications/mimeinfo.cache Deleted
[10:13] <seb128> Event to /usr/bin/epiphany : 1, 9, /usr/local/share/applications/mimeinfo.cache None
[10:13] <seb128> ...
[10:13] <seb128> it has things like that
[10:14] <Amaranth> inotify-test spit out the fact that someone touched ~/.bashrc but not that i created ~/foo
[10:14] <seb128> Amaranth: the gnome-vfs code for inotify didn't change a lot recently, if you have issues with it might be inotify itself  
[10:14] <Amaranth> i dunno if the tool is broken or if inotify is but it's only spitting out the first event
[10:15] <dholbach> mvo is here! we're saved!
[10:15] <desrt> oh that's annoying.
[10:15] <Amaranth> desrt: ?
[10:15] <ajmitch> hey mvo 
[10:16] <seb128> "(evolution-2.8:9185): e-utils-WARNING **: calling e_icon_factory_get_icon_filename with unknown icon_size value (48)"
[10:16] <desrt> i tried to replace gam_server with a shellscript that didn't deparent itself so i could see in ps who is responsible for spawning it
[10:16] <seb128> hates evolution
[10:16] <desrt> dholbach++
[10:16] <desrt> turns out the cliend-side library is does the deparenting on fork before execing
[10:17] <desrt> seb128; have you seen daniel's "Evolution GRRRRRRRRRR" icon?
[10:17] <ajmitch> mvo: about pbuilder slowdowns - it's repeatedly doing apt-get -s install <large number of packages>
[10:17] <Amaranth> so i'm thinking inotify is b0rked
[10:17] <mvo> ajmitch: thanks, let me have a look
[10:18] <desrt> Amaranth; why would you say this?
[10:18] <Amaranth> desrt: inotify_test only spits out one event
[10:18] <Amaranth> desrt: after that it shows nothing until i restart it, then it shows one more event
[10:19] <desrt> uhm
[10:19] <desrt> are you doing stuff?
[10:19] <Amaranth> yes
[10:20] <Amaranth> touch foo && rm foo
[10:20] <Amaranth> only the touch shows up
[10:20] <desrt> is it watching foo?
[10:20] <Amaranth> it's watching ~
[10:20] <desrt> hm
[10:20] <Amaranth> and i'm making foo in ~
[10:20] <desrt> i don't think inotify is "b0rked" enough to cause gnome-vfs to decide to not use it
[10:22] <seb128> desrt: yeah, and to be honest I did have to --force-shutdown evolution for some time now with edgy because it locked, I'm wondering if they fixed the frequent lock it used to face
[10:22] <seb128> Amaranth: does gnomevfs-monitor works fine for you? it does on my desktop
[10:22] <Amaranth> yep
[10:23] <desrt> seb128; evolution is in a sad state
[10:23] <desrt> seb128; all of the people who would be good maintainers for it are burned out from it
[10:23] <Amaranth> gnomevfs-monitor shows creation and removal
[10:23] <Amaranth> if gam_server would respond to SIGUSR2 i would be able to tell if it was handling those events
[10:23] <desrt> gnomevfs-monitor does an alarming number of syscalls
[10:24] <desrt> i think someone ought to talk to john again about how polling inside a filesystem monitor is evil :)
[10:24] <desrt> seems to wake up every ~100ms
[10:25] <desrt> no wonder battery life is so poor :p
[10:25] <desrt> nautilus is doing this 24/7... waking up every 100ms and doing a whack of syscalls
[10:26] <desrt> holy crap
[10:26] <desrt> i wonder if anyone knows about this bug
[10:27] <desrt> no lart.  just a friendly bug report :)
[10:28] <seb128> desrt: please open a bug on bugzilla and Cc him ;)
[10:30] <desrt> seb128; i think he watches the component
[10:30] <desrt> http://bugzilla.gnome.org/show_bug.cgi?id=348748
[10:30] <Ubugtu> Gnome bug 348748 in Monitoring (inotify) "nautilus wakes up about 10 times a second" [Normal,Unconfirmed]  
[10:31] <seb128> desrt: ok, cool
[10:31] <desrt> i think i have a new mantra
[10:31] <seb128> right, it's assigned to him
[10:31] <desrt> benm can go around yelling at everyone about memory use
[10:31] <desrt> i'm gonna go around yelling at everyone about syscalls
[10:31] <desrt> an idle system should be idle, damnit
[10:37] <desrt> oo.  battery applet is a prime offender
[10:37] <desrt> i'll have to fix that or have egg on my face!
[10:38] <dholbach> you rock, that's why! :-)
[10:38] <pitti> *blush* you too!
[10:38] <pitti> and the whole crowd
[10:38] <desrt> hello pitti :)
[10:39] <Amaranth> (btw, inotify_test is indeed broken, things works fine in pyinotify)
[10:40] <desrt> it'd be cool if you could strace the entire system
[10:40] <Amaranth> stupid gam_server though, it's killing my battery :P
[10:40] <Amaranth> desrt: it's funny that a battery applet actually does evil things to (minorly) reduce battery life
[10:40] <desrt> Amaranth; i noted the irony in my bug report against myself :)
[10:41] <desrt> i wonder if maybe gvfs falls back to gamin when inotify runs out of handles
[10:42] <desrt> has anyone heard anything new about that new netlink socket based file notification api?
[10:43] <desrt> the impression i get is that inotify seriously sucks and that all attempts to improve it are being fiercely faught against by linus
[10:43] <desrt> (or so john told me over coffee)
[10:43] <Treenaks> desrt: 
[10:43] <Treenaks> desrt: does linus give reasons for this fighting?
[10:44] <desrt> yes.  they're even good reasons.
[10:44] <desrt> inotify works by you telling the kernel what inodes you want to watch
[10:44] <desrt> user processes could theoretically fork many many copies of themselves
[10:44] <desrt> and file many many watches on files belonging to other users
[10:45] <desrt> causing file IO done by those users to slow to a crawl
[10:45] <desrt> so there's a per-user watch descriptor limit
[10:45] <desrt> the problem is that it's very easy to hit that limit
[10:45] <desrt> if you have beagle running, for example, you're practically guarenteed to hit it
[10:46] <desrt> so, as a fallback, because you can't always get an inotify handle, you have to resort to polling
[10:46] <desrt> it's insane
[10:46] <desrt> also, because inotify is inode based, there is no way to say "notify me when a file called "/home/desrt/foo/bar/baz is created"
[10:46] <dholbach> can somebody please get jokosher out of NEW?
[10:46] <desrt> you have to watch /home/desrt and "foo was created" events
[10:47] <desrt> then watch "foo" for "bar was created events (and hope you didn't miss one in a race), etc
[10:47] <desrt> so this is another case where the gnomevfs inotify code polls
[10:48] <desrt> dholbach; is muine-shell in edgy?
[10:48] <dholbach> desrt: i have no idea
[10:48] <seb128> dholbach: that's like your daily question :p
[10:48] <dholbach> seb128: I didn't ask yesterday.
[10:48] <Mithrandir> desrt: any idea why linus absolutely wants it to be inode-based?
[10:48] <desrt> dholbach; better ask twice today, then :)
[10:48] <seb128> ah, sorry, "almost daily" :)
[10:48] <desrt> Mithrandir; uhm.... as far as i know he doesn't?
[10:48] <desrt> Mithrandir; inode-based, i think, was john's design decision
[10:49] <desrt> Mithrandir; linus only insists on the per-user limits
[10:49] <desrt> Mithrandir; oh.  i think he also disliked the /dev/inotify business and insisted on syscalls, too :)
[10:50] <desrt> anyway... it's stupidly past my bedtime.. goodnight, all.
[10:50] <desrt> seb128; good luck to you.
[10:50] <dholbach> desrt: sleep tight
[10:50] <desrt> surely will.  i'm spent!
[10:50] <desrt> so much ranting :)
[10:50] <seb128> 'night desrt
[10:52] <Kamion> pitti: first-stage, but by chrooting, not as a udeb - so I think it does need to be added to the blacklist
[10:53] <Kamion> pitti: (thanks!)
[10:53] <pitti> ok
[10:56] <seb128> Kamion: I don't know if you do NEW processing atm or if that's Keybuk, but the new evolution-data-server has libedataserverui1.2-8 libedata-cal1.2-5 libebook1.2-9 libegroupwise1.2-12 as new binaries (soname changes) (dunno if listing new packages make your job easier)
[10:56] <seb128> would be nice to direct them to main when they are accepted too :)
[10:57] <Kamion> seb128: I've accepted the ones that are there
[10:57] <dholbach> ogra: you might want to subscribe yourself or the edubuntu-bugteam to dia - bug 49386 has a patch, that was not responded too
[10:57] <Ubugtu> Malone bug 49386 in dia "Export to pstricks work not if locale have wrong separator" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/49386
[10:57] <seb128> Kamion: ok, thank you
[10:58] <Kamion> seb128: and you forgot about libexchange-storage1.2-2 :-)
[10:58] <seb128> ups, right ;)
[11:00] <dholbach> It'd also be nice if libgucharmap5 and libgucharmap5-dev and gtk2-engines could make their way into main and the distro - I'm going to change the seeds afterwards
[11:00] <ogra> dholbach, thanks for the heads up, i thought edubuntu-bugs is already subscribed to dia
[11:01] <dholbach> seb128: and I'll add  gnome-keyring-manager  to desktop - it has been reviewed for main inclusion for a while
[11:02] <Kamion> dholbach: jokosher done, sorry for the delay
[11:02] <dholbach> Kamion: YOU ROCK! :)
[11:03] <Kamion> gucharmap binaries accepted
[11:03] <dholbach> super, thanks
[11:04] <Kamion> should be easier now than it was; the bound-branch thing is more convenient here than having to remember to push
[11:05] <Kamion> gtk2-engines binaries also accepted
[11:05] <dholbach> super - thanks a lot
[11:09] <dholbach> seed changes done
[11:09] <dholbach> Kamion: I agree, that was absolutely painless
[11:10] <seb128> dholbach: sure for gnome-keyring-manager, do you do the other updates like pessulus too?
[11:10] <dholbach> seb128: hm?
[11:11] <dholbach> seb128: which updates? pessulus doesn't seem to have a MIR
[11:11] <seb128> dholbach: pessulus is not to desktop but it's a part of the GNOME desktop, I think we should have it
[11:11] <dholbach> ogra: you will need pessuls, right?
[11:11] <seb128> dholbach: since you are taking care of having non-listed things listed now, I though you would do it for pessulus too
[11:11] <seb128> dholbach: like doing the wiki page etc
[11:11] <ogra> dholbach, yes
[11:12] <ogra> dholbach, as well as sabayon
[11:12] <dholbach> super, somebody else who writes the MIR! :-)))))
[11:12] <ogra> didnt i do that already ? 
[11:13] <seb128> Daniel "I read every single wiki commit" Holbach would have noticed
[11:13] <dholbach> hahahahahahaa
[11:13] <seb128> :)
[11:13] <ogra> lol, ok
[11:14] <ogra> i really thought i did that last week :)
[11:14] <ogra> but its actually not there
[11:23] <pitti> G0SUB: ping
[11:39] <rodarvus> pitti, oh, good to know
[11:40] <rodarvus> I didn't knew if urgency was respected on ubuntu, so decided to follow the debian policy on this upload
[11:40] <pitti> rodarvus: it doesn't hurt at all
[11:40] <rodarvus> (though I suspect the debian packaging policy would tell me to use urgency=medium)
[11:40] <pitti> rodarvus: it might just be interesting to you
[11:40] <Kamion> it affects apt-listchanges sorting, and users who read changelogs might look at it
[11:41] <pitti> rodarvus: urgency only affects testing migration; since we do not have testing, it doesn't matter for us
[11:41] <Kamion> (pretty minor really, of course)
[11:41] <pitti> rodarvus: hm, good point from Kamion, though
[11:42] <ogra> ARGH
[11:43] <ogra> was LP shut down ? i cant authenticate to get to the wiki 
[11:43] <Kamion> chinstrap being down temporarily might affect things I guess?
[11:43] <ogra> meh
[11:44] <Kamion> though I didn't know the authserver lived there
[11:44] <ogra> luckily i have a preview in my cache
[11:44] <Kamion> Malone is accessible
[11:45] <ogra> "The authentication database is temporarily unavailable. Anonymous access only."
[11:46] <ogra> is what i get from the wiki
[11:54] <sivang> morning
[12:13] <jono> hey
[12:14] <ajmitch> hi jono 
[12:14] <jono> hey ajmitch
[12:16] <slomo_> Riddell: why did you add the splash header to libpoppler-dev? we build the cairo version now, not the splash version
[12:16] <Riddell> slomo_: it's needed for kpdf
[12:17] <ogra> iwj, hmm, youre right, the SCP spec doesnt say anywhere that the gui is run by gksu, thanks for pointing
[12:17] <slomo_> Riddell: that sounds more like a kpdf bug... why would it need the splash headers if there is absolutely no splash functionality anymore? do you have the url to a build log?
[12:18] <Riddell> slomo_: only on my local machine
[12:19] <pitti> dholbach: how did you manage to upload two different diff.gz/dsc of jokosher with the same version number? :)
[12:20] <slomo_> Riddell: ok, i'll take a look at it myself then...
[12:20] <Riddell> slomo_: of course this might explain why people are complaining that kpdf doesn't work
[12:22] <slomo_> Riddell: hrm, the qt bindings only support splash it seems... so we must enable both probably...
[12:22] <dholbach> pitti: they were sitting in NEW and soyuz didn't discard one of them
[12:23] <ajmitch> pitti: I think it's called soyuz being special
[12:23] <slomo_> Riddell: i'll care for that :)
[12:26] <Kamion> dholbach: oh I just forgot to reject the other one
[12:26] <Kamion> shouldn't make any difference to anything in practice
[12:26] <Kamion> (since the newest version accepted was greater than the duplicate pair)
[12:26] <dholbach> *happy* beam
[12:31] <highvoltage> nice beam.
[12:33] <slomo_> Riddell: yes, the poppler qt bindings are completely broken when only using cairo... will be fixed with next upload :)
[12:34] <seb128> slomo_: how will it be fixed?
[12:34] <slomo_> seb128: by enabling splash and cairo... the cairo stuff is only used in the glib bindings anyway and not in libpoppler itself
[12:35] <slomo_> seb128: but i have to test it before... that's only theory now ;)
[12:35] <iwj> ogra: Oh, the SCP UI runs as root ?!
[12:35] <ogra> iwj, yup, it needs to it kills shh sessions of users :)
[12:35] <iwj> ogra: Right, well, I suppose if it can run commands as anyone then it's root-equivalent anyway.
[12:35] <seb128> slomo_: you can't build with both
[12:36] <iwj> If you didn't need to run commands as users you could have a userv service (or sudo config if you must) for killing ssh sessions or whatever.
[12:36] <ogra> iwj, yup ... i think thats the key  which i missed to write doen ... also the system dbus will only allow access as uid 0
[12:36] <ogra> so all that auth stuff ist really relevant (a nice add on though)
[12:36] <Amaranth> ogra: that's fixable (dbus)
[12:36] <slomo_> seb128: why? at least configure is able to enable both at the same time
[12:36] <ogra> *isnt
[12:36] <iwj> Right.  Write down where that's configured, too.
[12:37] <iwj> I mean, where it's configured who gets access to the system dbus.
[12:37] <ogra> well, i dbus indeed
[12:37] <iwj> Or if it's not a matter of configuration, where it's documented.
[12:37] <seb128> slomo_: how would you have both used together?
[12:37] <iwj> ogra: Also, what's all that stuff about S/Key ?
[12:37] <ogra> i dont understand why i should reference to every possible protocol or mechanism here since we only use the implemented one in dbus ...
[12:37] <iwj> Are you sure you're going to be using that ?
[12:38] <ogra> i'm using what the dbus spec proposes as default
[12:38] <iwj> dbus will use a SASL library so it can do everything our SASL can.
[12:38] <ogra> which is SASL with SKEY
[12:39] <iwj> I can't see that in the dbus spec you have a reference to.
[12:39] <iwj> And it seems wrong really.  S/Key is for one-time passwords.
[12:39] <slomo_> seb128: the glib bindings use cairo, the others use splash. works fine here at least with evince and pdflatex...
[12:39] <seb128> slomo_: and what is doing atm?
[12:39] <ogra> but based on the fact that only root can access a dbus service thats run as root (system bus) its not relevant at all i think ... mind if i wipe the auth stuff completely ? 
[12:39] <iwj> reference to every possible protocol> Obviously you should provide references for the ones you're going to be using, but not others.
[12:40] <iwj> ogra: I don't know if it's relevant.  How does it work that only root can access the dbus system bus ?
[12:40] <slomo_> seb128: the current version disables splash and the qt bindings then have undefined references to the splash stuff (which are not noticed at build time because of no -Wl,--no-undefined)
[12:40] <ogra> but i dont care what dbus uses ... it will use the same auth it uses for all other system services 
[12:40] <ogra> thats why i rely on a existing framework with proven security
[12:41] <iwj> If it does it by having some kind of authentication protocol over the connection to the dbus daemon then you should say that and which protocol it's using etc. (probably by giving a reference to the config file or a manpage or something).
[12:41] <ogra> i *can* find out how dbus does that, but is it really necessary to describe it detailed because i want to use it ?
[12:41] <iwj> If it does it some other way then surely it must be documented somewhere ?
[12:41] <ogra> well, it will use the standard dbus innings 
[12:41] <iwj> Well, if it's a well-known fact that only root can access the system dbus then fine.
[12:41] <ogra> ok
[12:41] <iwj> Just state it.
[12:41] <seb128> slomo_: if the other don't use splash, not cairo what do they use? it's not really clear ...
[12:41] <ogra> i'll clean up the spec
[12:42] <iwj> (But then I'm confused as to how the program-running-as-user can get these please-execute-command messages.)
[12:42] <ogra> the same way nm-applet gets messages from NetworkManager
[12:42] <iwj> I know nothing about that.
[12:42] <ogra> the session bus listens for messages on the system bus ... 
[12:43] <iwj> Doesn't the session bus run as the user ?
[12:43] <ogra> the tool thats the listener is waiting for specific namespaced messages
[12:43] <slomo_> seb128: the qt bindings only use splash but as libpoppler-splash is not build and not statically linked against it it has missing symbols. the glib bindings can use splash but use cairo if it is enabled (or did i misunderstand your question?)
[12:43] <ogra> yup
[12:43] <ogra> but the session bus can pick up messages from the system bus
[12:43] <iwj> So if it runs as the user how can it connect to the system bus which you just told me only root can connect to ?
[12:43] <ogra> i.e. hal, g-p-m or nm do that
[12:44] <Mithrandir> iwj: look at /etc/dbus-1/system.d/* for various ACLs for different end points on the system bus.
[12:44] <ogra> it cant *send* 
[12:44] <ogra> but it can listen for messages
[12:44] <iwj> Mithrandir: Thanks, that's the information we're looking for I think.
[12:44] <iwj> ogra: You should provide references to the access control configuration and documentation.
[12:44] <ogra> ok
[12:44] <iwj> You don't have to redescribe everything.
[12:45] <seb128> slomo_: I just find weird to have the glib bindings using cairo and poppler itself using splash, but if you say that works fine ...
[12:45] <ogra> i think i had a reference to /etc/dbus-1/system.d/ i te first one before i started to change everything :)
[12:45] <iwj> Your spec can pretty much assume that people know all about the stuff you're using but you have to provide references so that if they don't know they can go and read something to find out.
[12:45] <iwj> And a reference to which manpage or dbus doc or whatever specifies the meaning of those files.
[12:45] <iwj> And you should say whether you plan to change them at all.
[12:46] <iwj> `We will add a new ACL entry so that ...' or some such.
[12:46] <ogra> iwj, i was falsesly assuming that people know the existing SCP ... so i didnt add the info about gksudo :)
[12:46] <ogra> *falsely
[12:46] <slomo_> seb128: libpoppler itself doesn't use splash or cairo. only the bindings use one of the two
[12:46] <ogra> the initial spec pointed to /etc/dbus-1/system.d/ ad that services files for auth and namespace are added there, but didnt explain it further
[12:47] <seb128> slomo_: ok, if you don't break poppler-glib feel free to do any change you want :)
[12:47] <iwj> ogra: Well, if there had been a reference to the existing SCP specification you might get away with that.  But of course the more specific to your project, or the more obscure, the more you might have to state nonobvious things.
[12:47] <ogra> yep
[12:47] <iwj> ogra: Do those files contain access control as well as binding information, then ?
[12:47] <iwj> That wasn't clear to me.
[12:48] <ogra> it has a <policy> tag in the xml which enables ACLs
[12:48] <ogra> see /etc/dbus-1/system.d/nm-applet.conf for example
[12:50] <ogra> hal.conf is even better it has some finer grained stuff there 
[12:50] <iwj> *vomit*
[12:50] <iwj> XML configuration files.
[12:50] <ogra> heh, yes
[12:50] <ogra> agreed :)
[12:50] <Treenaks> iwj: sounds like a webbrowser I know
[12:50] <iwj> That's _not what xml is for_.
[12:50] <ogra> Treenaks, dbus rather :)
[12:50] <iwj> Treenaks: Don't get me started.
[12:50] <Amaranth> so, uh, if a have a ~/.evil/nm-applet can i get on the system busZ?
[12:50] <Amaranth> -Z
[12:50] <ogra> Amaranth, nope
[12:50] <ogra> the system bus wont read from that
[12:51] <iwj> ogra: Right, I see now.  I think if you include your proposed system.d file in the spec (or an example of it) then things will be much clearer.
[12:51] <Amaranth> how does it decide what to allow?
[12:51] <iwj> It's OK to put important interface definitions and so on in specs.
[12:51] <ogra> iwj, ok, so i'll add a note about uid 0 and attach the xml ...
[12:52] <ogra> Amaranth, based on /etc/dbus-1/system.d/ .... where users dont have write access :)
[12:53] <doko> Riddell: kdelibs4-dev is uninstallable on sparc and powerpc?
[12:53] <iwj> ogra: And get rid of all that sasl stuff if it's not relevant :-).
[12:53] <ogra> :D
[12:53] <ogra> will do that happily :)
[12:54] <Amaranth> ogra: I know that. :P If /etc/dbus-1/system.d/nm-applet.conf exists would it work though?
[12:54] <Riddell> doko: it was ok last I tried on powerpc, let me look
[12:55] <doko> Riddell: http://librarian.launchpad.net/3567531/buildlog_ubuntu-edgy-sparc.openoffice.org_2.0.3-3ubuntu3_FAILEDTOBUILD.txt.gz
[12:56] <ogra> Amaranth, you cant override the system bus in userspace ... 
[12:56] <Amaranth> *facepalm*
[12:57] <Amaranth> dbus considers /usr/bin/nm-applet and ~/.evil/nm-applet to be different things and doesn't allow access to the second one?
[12:58] <ogra> ah, you mean a separate backend binary ... not a services file
[01:00] <Amaranth> ogra: yeah, i already have nm-applet installed and it has it's .conf file in place, i just want to abuse the .conf file for my own purposes
[01:00] <Amaranth> how does it tell the difference between the real nm-applet and my fake one that does evil things like flood the bus
[01:02] <Amaranth> holy shit it doesn't
[01:03] <Amaranth> oh, duh
[01:03] <Amaranth> it lets me connect to the bus but not access anything
[01:04] <Amaranth> i wonder if i can flood it trying to access things or if that's handled in the client libraries
[01:04] <ogra> Amaranth, work on your SoC project instead of searching dbus exploits :P
[01:04] <Amaranth> heh
[01:10] <Riddell> doko: seems like mesa-common-dev and libgl1-mesa-dev are out of sync
[01:10] <Riddell> libgl1-mesa-dev: Depends: mesa-common-dev (= 6.5.0.cvs.20060725-0ubuntu1) but 6.5.0.cvs.20060524-1ubuntu1 is to be installed
[01:11] <ajmitch> Riddell: i386?
[01:11] <Riddell> yes
[01:12] <Riddell> or do I have to change the gl depends on qt?
[01:12] <ajmitch> buildds are still catching up, it seems
[01:12] <ajmitch> blocked by OOo :)
[01:13] <doko> OOo doesn't block anything, just underpowered buildd's ...
[01:13] <ajmitch> doko: that's what I meant, really :)
[01:13] <rodarvus> yeah, why should two 12 hours build block anything? :)
[01:17] <rodarvus> hmm, strange, vernadsky is idle -> https://launchpad.net/+builds/vernadsky
[01:17] <rodarvus> shouldn't it pick the next item in the queue automatically? (or openoffice.org build being for dapper has any effect on it?)
[01:18] <ogra> rodarvus, ist that crontab driven ?
[01:19] <rodarvus> could be, but the openoffice.org build finished 9 minutes ago.
[01:19] <ogra> iwj, spec updated .... i added a note about UID 0 and a commented services file ...
[01:19] <rodarvus> I don't expect the crontab to take so long to pick up
[01:20] <Mithrandir> iwj: what's a useful way to debug "firefox doesn't load some pages at all" problems?  For instance. www.brygging.no doesn't work from this machine.  I've tried nuking ~/.firefox and ~/.mozilla.  Also, it seems to affect epiphany.
[01:21] <ogra> sure thats not a network thing ? 
[01:22] <ogra> i.e. did you try links 
[01:22] <rodarvus> Mithrandir, might be the same bug I was bitten when trying to access gmail
[01:22] <Mithrandir> ogra: yes, it works fine with lynx.
[01:22] <Mithrandir> rodarvus: which bugs is that?
[01:22] <rodarvus> edgy firefox has a stripped browser id line
[01:22] <rodarvus> missing Gecko/2006<something>
[01:22] <iwj> www.brygging.no> WFM
[01:22] <rodarvus> I reported it to iwj a few days ago
[01:23] <rodarvus> (didn't open a LP ticket, though)
[01:23] <crevette> mee too
[01:23] <ogra> yes, i see a lot of beer too 
[01:23] <Mithrandir> it seems to hang after loading a bit of data, but I haven't tcpdumped it yet.
[01:23] <iwj> I don't think the browser string is relevant here.
[01:23] <crevette> the bug on gmail exist since end of june
[01:23] <iwj> Mithrandir: PMTU ?
[01:23] <iwj> I take it you're not knowingly using any kind of proxy.
[01:24] <rodarvus> Mithrandir, this page loads successfully here
[01:24] <rodarvus> (with epiphany and firefox)
[01:25] <Mithrandir> iwj: it seems to load a bit more when I lowered it from 1500 to 500.  No proxies involved and my provider doesn't do transparent proxying.
[01:26] <iwj> I think links working is probably a red herring as it doesn't load images.
[01:26] <rodarvus> (returning to the buildd subject) should I worry about vernadski being idle or is it expected?
[01:26] <iwj> It sounds to me like you have network problems.
[01:27] <iwj> I suppose you could try wget -p.
[01:28] <Mithrandir> iwj: well, dillo works.
[01:28] <Mithrandir> or, "works".  It renders it quite badly, but it loads in no time.
[01:29] <iwj> If you set network.http.max-connections to 1 in about:config, does it help ?
[01:30] <iwj> I don't want to rule out ff being at fault but I'm still with the network problem theory.
[01:30] <Mithrandir> iwj: doesn't seem to change anything, no.
[01:34] <chris^> Hi
[01:34] <chris^> I Have an idear for Edgy and XGL, a little FeatureRequest, where shoud i Post this?
[01:34] <Kamion> links> try w3m with w3m-img installed
[01:35] <Kamion> oh, if dillo works then I guess that's moot
[01:35] <ogra> chris^, likely in the motu channel, but probably not even there since intrest in maintaining XGl is very low there 
[01:35] <Mithrandir> yeah, I doubt it's my network.  It's been like that on some sites for a few days and !gecko browsers seem to work.
[01:36] <chris^> ogra: well, I have just the idear, that there shoud be an extra loginsession for XGL per default... 
[01:36] <ogra> chris^, we wont support XGL so "default" is already out of discussion ...
[01:37] <chris^> ogra: _default_ if you are installing XGL ;)
[01:37] <mjg59> ogra: ajmitch was looking at updating the Xgl build last night
[01:37] <mjg59> Now that we have fresh enough mesa
[01:37] <ogra> mjg59, oh, really ? 
[01:37] <ajmitch> ogra: yes, I built a fresh Xgl from the git tree
[01:37] <mjg59> And I'll try to help rodarvus with aiglx
[01:38] <ogra> mjg59, what for now that we get xorg 7.1 with all the fun in it ?
[01:38] <mjg59> ogra: xgl works better with some of the binary drivers
[01:38] <ogra> ah
[01:38] <Treenaks> just buy intel ;)
[01:38] <mjg59> Yeah
[01:39] <ajmitch> Treenaks: that works for my laptop, but not my nvidia-using desktop box
[01:39] <seb128> we have tried on #ubuntu-desktop to push that guy uslab to get people working on some xgl ubuntu packages out of ubuntu, contributing directly to universe yesterday  
[01:39] <maswan> Mithrandir: sure it isn't something silly like full $HOME or /tmp or so?
[01:39] <maswan> Mithrandir: In my experience, mozilla-based stuff gets lots of weird error modes as soon as something like that happens.
[01:40] <Mithrandir> maswan: 742MB free, so nope.
[01:41] <rodarvus> 742mb? I would become quite claustrophobic with that amount of free space on any partition :)
[01:41] <ogra> rodarvus, how much do you need to feel comfortable ? 
[01:41] <ogra> 1TB ?
[01:41] <Mithrandir> rodarvus: you're not my web browser. :-P
[01:42] <rodarvus> I need enough to uncompress/build large stuff without worrying
[01:42] <rodarvus> 10-20gb is ok
[01:42] <rodarvus> Mithrandir, :)
[01:42] <Robot101> 1.4G free
[01:42] <hungerW> rodarvus: I have /tmp for that.
[01:43] <ogra> oh, i just ran df -h for the first time on this knot 1 install 
[01:43] <ogra> /dev/evms/hda3         46G  1,8G   42G   4% /home
[01:43] <rodarvus> hungerW, I work all day long doing packaging. I can't risk putting this stuff in /tmp
[01:43] <ogra> do we default to evms now ?
[01:43] <ogra> i surely havent selected that during install
[01:44] <Kamion> no
[01:44] <rodarvus> my /boot was moved to /dev/evms recently too
[01:44] <ogra> hmm, how did i get there then ? weird ...
[01:44] <Kamion> I suspect the fstab migration (libvolumeid0) went a bit nuts
[01:44] <ogra> heh
[01:44] <Kamion> look at /etc/fstab
[01:45] <Kamion> also perhaps mount-by-UUID is getting things wrong
[01:45] <rodarvus> O_O
[01:45] <ogra> WOAH
[01:45] <Kamion> ?
[01:45] <rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/done$ wc -l /etc/fstab
[01:45] <rodarvus> 71 /etc/fstab
[01:45] <rodarvus> rodarvus@wakko:~/canonical/code/merges/seven-dot-one/done$
[01:45] <ogra> # /dev/hda3 -- converted during upgrade to edgy
[01:45] <ogra> UUID=7c24e63d-e8f7-4738-93f5-a63edd2c641a /home ext3 defaults 0 2
[01:45] <Kamion> rodarvus: is it full of environment variables?
[01:45] <rodarvus> yes
[01:46] <Kamion> rodarvus: if so, delete all those; I fixed that yesterday morning but there's no sane way to deal with people who upgraded through the breakage
[01:46] <rodarvus> *nods*
[01:46] <rodarvus> Kamion, thanks
[01:46] <Mithrandir> the migration broke for me, but I'm using evms, so.
[01:47] <Kamion> ogra: UUID= is normal, but try 'blkid -t UUID=7c24e63d-e8f7-4738-93f5-a63edd2c641a'
[01:47] <Kamion> ogra: it returns stray evms crap for me too
[01:47] <Kamion> so I suspect something's wonky in libblkid
[01:47] <ogra> well, it returns two lines for me
[01:47] <Kamion> bug Keybuk about it when he wakes up
[01:47] <ogra> one with and one without evms
[01:47] <Kamion> right, likewise
[01:48] <Mithrandir> Kamion: for extra winnage::
[01:48] <Mithrandir> : tfheen@golem ~ > blkid -t UUID=e956b7b4-6ebf-4bd4-98ac-ffa52eb26028
[01:48] <Mithrandir> /dev/evms/.nodes/lvm/lvm0/home0: LABEL="home0" UUID="e956b7b4-6ebf-4bd4-98ac-ffa52eb26028" SEC_TYPE="ext2" TYPE="ext3"
[01:48] <Kamion> so, it's probably harmless and will be sorted out once the blkid bug is fixed
[01:48] <ogra> lol
[01:48] <Mithrandir> and trying to open that gives an error.
[01:48] <ogra> seems to be harmless given i didnt recognize it until looking at df
[01:48] <Kamion> we shouldn't be UUIDing LVM anyway, as some bug report pointed out
[01:48] <Kamion> that probably goes for EVMS too, not sure
[01:48] <Mithrandir> on-disk format of LVM and EVMS is the same.
[01:52] <rodarvus> infinity, ping
[01:55] <cprov> infinity: buildd-sequencer is stopped, buildds can't resolve librarian name.
[01:56] <elmo> cprov: that was a temporary thing
[01:57] <elmo> for like 10-15 mins top, 3 hours ago
[01:57] <elmo> it should be fine now - can you restart it or otherwise kick it?
[01:57] <elmo> (or do I need to?)
[01:57] <cprov> elmo: yes, let's try
[01:59] <cprov> elmo: looks like happening again, check last lp-error mail.
[01:59] <elmo> cprov: let's take this to ##soyuz1.0
[02:00] <cprov> elmo: okay
[02:09] <infinity> rodarvus: pong?
[02:10] <rodarvus> infinity, solved now, thanks
[02:10] <infinity> Okay, good, cause I'm tired. :)
[02:11] <rodarvus> infinity, buildds were mostly idle
[02:11] <rodarvus> due to dns failure on the DC
[02:11] <rodarvus> cprov and elmo fixed it
[02:11] <rodarvus> infinity, go take some rest :)
[03:24] <iwj> What happened to the `is the hardware clock set to GMT' question ?
[03:26] <zul> can someone new xen-source-2.6.16 when they get a chance please thanks
[03:29] <ogra> iwj, probably dropped for people sitting near greenwitch ? :)
[03:31] <maswan> ogra: but greenwitch doesn't run on GMT though, right? :)
[03:31] <ogra> pfft ...
[03:31] <ogra> :)
[03:32] <Mithrandir> mdke: you prefer blue witches?
[03:33] <mdke> Mithrandir: pink
[03:33] <Vhata> sand witches
[03:33] <doko> infinity, cprov: are there some estimates/docs, how long it does take from an upload to upload.u.c until the binary packages appear in the archive (ignoring the build times)
[03:33] <jjesse> mmmmm sandwidch
[03:40] <pitti> Mithrandir: do you have some time today to peer review a PAM code snippet?
[03:41] <Mithrandir> pitti: sure.  Now?
[03:41] <pitti> Mithrandir: I just wrote a setgid shadow helper program for cups pam authentication
[03:41] <pitti> Mithrandir: whenever you have time
[03:41] <Mithrandir> pitti: I can do it now; do you have an URL or bzr repo?
[03:42] <pitti> Mithrandir: http://people.ubuntu.com/~pitti/tmp/cups_check_pam_auth.c
[03:42] <pitti> Mithrandir: I designed it that way: cups writes 'username\0password' to stdin of that program
[03:42] <pitti> Mithrandir: and the return code determines whether it's succeeded or not
[03:42] <joejaxx> haha it seems rm -rf does not work on my system anymore 
[03:43] <pitti> Mithrandir: gcc -Wall -W cups_check_pam_auth.c -lpam
[03:43] <Kamion> iwj: it's still asked under many circumstances, but not always
[03:43] <pitti> Mithrandir: echo -ne "foo\0bar" | sudo ./a.out
[03:43] <Mithrandir> pitti: this'll be gid shadow and uid cupsys with mode 2750?
[03:43] <pitti> Mithrandir: of course eventually setgid shadow will suffice (I intend it to be cupsys:shadow 2744)
[03:43] <Kamion> (it last changed in May)
[03:44] <iwj> Kamion: May> Hmm.  It seems to be getting the answer wrong for me, eg on a dapper D-I install.
[03:44] <pitti> Mithrandir: 2754 works too, of course, 2744 is just paranoid
[03:44] <Kamion> iwj: details?
[03:45] <Kamion> iwj: the default may be wrong; that's fine as long as it's asked
[03:45] <Kamion> if Windows or another OS that requires the hardware clock to be in local time is installed, then it defaults to local time and doesn't ask
[03:46] <Mithrandir> oh, nice, you don't have to be root to mlock any more.  (Up to RLIMIT_MEMLOCK, at least)
[03:46] <Kamion> otherwise it defaults to UTC and asks
[03:46] <pitti> Mithrandir: right
[03:46] <iwj> Kamion: Ah, it's probably seeing the W98SE that's sitting around on this disk.
[03:46] <pitti> Mithrandir: that's why we could un-setuid gnupg since warty
[03:46] <iwj> That's unfortunate because the hardware clock is in UTC and obviously I don't care about 'doze's clock.
[03:46] <pitti> Mithrandir: (some of the sanity checks are not necessary, I just want to be on the safe side)
[03:47] <Kamion> you can preseed clock-setup/utc=true to work around that
[03:47] <Mithrandir> pitti: won't sizeof always return something which is ssize_t?
[03:47] <pitti> Mithrandir: not sure about whether it's size_t or ssize_t
[03:47] <Kamion> should be size_t
[03:47] <pitti> Mithrandir: it would be more logical to be size_t
[03:50] <Mithrandir> pitti: hmm, it seems like you should make sure both input values are null-terminated.  As it is, you can end up not reading all the input.
[03:50] <pitti> Mithrandir: how so?
[03:50] <Mithrandir> it's a kinda a contrived case, but it bit us in usplash, for instance.
[03:51] <pitti> Mithrandir: if I read more than or equal to sizeof(buffer), I abort with 'input overflow'
[03:51] <bddebian> Hello
[03:51] <Mithrandir> yes, I'm not talking about that case.
[03:51] <Mithrandir> pitti: think a program which does write(fd, "username\0", 9); write(fd, "password", 8);
[03:51] <pitti> Mithrandir: oh, I see
[03:52] <pitti> Mithrandir: I thought read() would block until eof is reached
[03:52] <pitti> Mithrandir: as long as the requested size is not yet read
[03:52] <pitti> if it doesn't, that makes things much more complicated
[03:53] <iwj> root@samual9:/# wc -l /boot/grub/menu.lst
[03:53] <iwj> 11028 /boot/grub/menu.lst
[03:53] <iwj> ROTFL
[03:53] <Kamion> pitti: it won't necessarily, no
[03:53] <iwj> Maybe that's why my grub isn't working.
[03:53] <Kamion> don't tell me grub has a limit?
[03:53] <Mithrandir> iwj: wow.
[03:53] <Mithrandir> 11k lines sounds a bit excessive.  Sure you don't hit the 640KB limit?
[03:54] <pitti> Mithrandir: (I added some documentation bits and re-uploaded)
[03:54] <ogra> wow, how many kernel entries do you have with 11k lines
[03:54] <iwj> root@samual9:/media/hda8/boot# wc grub/menu.lst
[03:54] <iwj>  11028  47216 351671 grub/menu.lst
[03:54] <Mithrandir> pitti: just require both to be null-terminated and abort if you haven't seen two nulls before hitting the maximum size of your input buffer?
[03:54] <iwj> title           debian (on /dev/hda5) (on /dev/hda7) (on /dev/hda8) (on /dev/hda
[03:54] <iwj> 9) (on /dev/hda8) (on /dev/hda7) (on /dev/hda9)
[03:54] <zul> ogra: migth want to clean that up a bit 
[03:55] <pitti> Mithrandir: I'd rather read data in a loop until I hit EOF
[03:55] <pitti> Mithrandir: but your's works as well, of course
[03:55] <iwj> You are lost in a twisty maze of grub menus all alike!
[03:55] <pitti> Mithrandir: I think I'll do both
[03:56] <Kamion> heh, I should really fix grub-installer not to do that
[03:56] <Kamion> it gets a bit insane after a while
[03:56] <Kamion> very useful for people who don't have ten installs ...
[03:57] <iwj> I think this might just possibly be why it doesn't boot.
[03:57] <bddebian> Kamion: What do I do about the rejects on those fakesysnc because of SHA1 sums?
[03:58] <Kamion> bddebian: well, you can't get the Debian .orig.tar.gz in the archive; we only ever have one file with a given name
[03:58] <Kamion> bddebian: so you need to compare the Debian and Ubuntu .orig.tar.gzs
[03:59] <Kamion> bddebian: it may well be that there are no interesting changes, and the upload will do just fine with the Ubuntu .orig.tar.gz
[03:59] <Kamion> bddebian: in which case you should upload a build1 built with the *Ubuntu* .orig.tar.gz and no -sa
[03:59] <Mithrandir> pitti: you're aware that you're disallowing blank passwords?
[03:59] <pitti> Mithrandir: yes
[03:59] <Kamion> bddebian: if the .orig.tar.gz files are materially different, that's harder - probably best to apply the relevant differences to the Ubuntu diff in that case
[04:00] <Kamion> but either way, you must upload with the Ubuntu .orig.tar.gz, and no -sa
[04:00] <bddebian> Kamion: OK
[04:00] <bddebian> thanks
[04:00] <Kamion> (In either case, whoever didn't use the pristine upstream tarball in the first place should be LARTed, assuming there was such a pristine tarball available.)
[04:01] <bddebian> Gloubiboulga: ping?
[04:02] <Gloubiboulga> bddebian, pong
[04:02] <bddebian> Gloubiboulga: You maintain prismstumbler?
[04:02] <Gloubiboulga> bddebian, not really, but the menu entry needs some love :)
[04:03] <bddebian> Gloubiboulga: There are a few new upstream releases
[04:03] <bddebian> I'm trying to build 0.7.3 but the build system has changed quite a bit
[04:03] <bddebian> I don't even see a make install anymore
[04:04] <Gloubiboulga> the debian maintainer hasn't updated his package I guess?
[04:04] <bddebian> Oh sorry, for some reason I thought I saw you as the Debian maintainer.. Duh..
[04:05] <Gloubiboulga> I don't maintain packages in debian (yet)
[04:05] <iwj> Kamion: can I chase someone about NEW for zul's xen-source-... et al ?
[04:06] <Mithrandir> pitti: I can't poke any holes in it, I think.  The conversion function's implicit assumption about message styles is a bit unfortunate, but I understand why it's done and agree it's not a problem.
[04:09] <pitti> Mithrandir: thanks for the review; I'm a bit stunned about read(), though; if I just sit around retrying to read if read returns 0, I'm stuck forever with above test command
[04:10] <pitti> Mithrandir: either bash does not close stdin when the echo command finishes, or read() does not fail with EBADF if stdin is EOFed
[04:10] <Mithrandir> pitti: make both be null-terminated, then?
[04:10] <pitti> Mithrandir: how does that help me?
[04:10] <Mithrandir> once you read the second NULL byte you know you're done and can continue.
[04:10] <pitti> hm
[04:10] <pitti> feels a bit unclean, but I guess I have to live with that
[04:11] <pitti> it'll mean the process sits around forever if it never receives two NULs
[04:12] <Mithrandir> why is that a bigger problem than cat sitting around forever unless it receives an EOF?
[04:12] <pitti> hm, true
[04:12] <iwj> Kamion: Is there a bug already about the exponentially multiplying menu entries, or should I file one ?
[04:12] <iwj> I've retitled bug 54041 to be the report that grub crashes if the menu is too long.
[04:12] <Ubugtu> Malone bug 54041 in grub "grub stage2 crashes if too many menu entries" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54041
[04:17] <Kamion> iwj: yes, bug 26031
[04:17] <Ubugtu> Malone bug 26031 in grub-installer "grub menu contains "combinatorial expansion" of existing installations" [Medium,Needs info]  http://launchpad.net/bugs/26031
[04:17] <iwj> I'll faff with that then, thanks.
[04:17] <Kamion> (pointlessly needs-info, -> confirmed)
[04:18] <Kamion> ok, that's revive-tasksel implemented bar the shouting^Wapplication of Launchpad patch
[04:20] <Kamion> infinity: you should be able to get going on ubuntu-server-tasks now, if you like; see the existing dns-server and lamp-server examples in the seeds
[04:20] <thom> Kamion: as an entertaining side note, the partitioner _really_ doesn't like not having any disks
[04:20] <Kamion> once we've tested the new code I'll remove the LAMP server boot option.
[04:21] <Kamion> thom: fixed in edgy
[04:21] <Kamion> we noticed that just before knot-1
[04:21] <thom> ah, cool
[04:21] <Kamion> combination of bugs in disk-detect and partman-auto
[04:22] <thom> heh, right
[04:22] <thom> i mean, i like blue. but forever is a bit long to stare at it ;-)
[04:24] <pitti> Mithrandir: new version is up; another look is appreciated
[04:24] <dholbach> Kamion: hum.... did you make that change to the seeds? i added  gnome-keyring-manager  to it as well (in the same commit), but can't see it in the ubuntu-meta changelog
[04:25] <pitti> Mithrandir: (echo -ne 'martin\000'; sleep 1; echo -ne 'secret\0') | sudo ./a.out <= works fine now, broke before
[04:25] <pitti> (yay for my consistent quoting of NUL bytes)
[04:29] <Mithrandir> pitti: looks correct to me
[04:30] <pitti> Mithrandir: great; thanks for the review
[04:30] <Mithrandir> np
[04:32] <Kamion> dholbach: gnome-keyring-manager hasn't been promoted to main yet
[04:33] <dholbach> ahhh! ok
[04:33] <Kamion> dholbach: your change worked fine, but the promotion needs to happen before ubuntu-meta picks it up
[04:33] <dholbach> can somebody promote it to main please? :)
[04:33] <Kamion> after this publisher run, yes
[04:34] <dholbach> thanks a lot
[04:34] <Kamion> Seveas: please stop rejecting bugs on my packages
[04:34] <Kamion> thanks
[04:35] <Seveas> Kamion, err, when did I?
[04:36] <Kamion> Seveas: bug 53656
[04:36] <Ubugtu> Malone bug 53656 in user-setup "user-setup insists on creating a user" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/53656
[04:37] <Kamion> if you do reject them, at least subscribe to the bug so that you can be argued with if you're wrong
[04:37] <Seveas> Kamion, I read ubuntu-bugs so I don't subscribe to bugs. And I rejected it because the user said "bug is bogus"...
[04:38] <Kamion> the user was mistaken; deciding whether to reject the bug is best done by somebody who knows the code
[04:38] <Kamion> and the user himself asked for further action anyway
[04:39] <Kamion> so basically please don't be so hair-trigger on the reject button
[04:44] <Lathiat> hrm edgys stuck on 'waiting for root device', any way around that?
[05:01] <Zdra> seb128: is it normal nautilus doesn't runs bugbuddy when it crash and I want to report the stack trace ?
[05:01] <seb128> Zdra: "and I want to report the stack trace"?
[05:02] <seb128> do you get the "app has crashed..." dialog?
[05:02] <Zdra> I can reproduce a crash, I click on "informer les developpeurs" to start bug buddy but it doesn't start...
[05:03] <dholbach> Zdra: is that on dapper or on edgy?
[05:03] <Zdra> edgy
[05:03] <dholbach> are the versions of libgnomeui-0 and bug-buddy 2.15.90-0ubuntu1?
[05:04] <Zdra> oh... bug-buddy is taking 100% CPU :p
[05:04] <seb128> dholbach: no they are not, he would not get that dialog other way
[05:04] <seb128> dholbach: the "informer les developpeurs" has been dropped with libgnomeui 2.15.90
[05:04] <seb128> Zdra: ah, not good :)
[05:04] <dholbach> ah, yes - seb128: i just wanted to know if he has one new version and one old version
[05:04] <Zdra> bug-buddy-2.15.0-0ubuntu1 and libgnomeui 2.15.2-0ubuntu1
[05:05] <seb128> bug-buddy 2.15.0 had issue to recognize a bunch of apps, dunno if nautilus if one of them
[05:05] <seb128> I think it was
[05:05] <seb128> but you should get a dialog saying the app is not known
[05:05] <seb128> the upgrade to 2.15.90 should fix that
[05:06] <seb128> it has been uploaded yesterday, so it should be available now or soon
[05:06] <Zdra> seb128: ok I upgrade... and I have my call stack of the crash with gdb :)
[05:06] <seb128> Zdra: according to launchpad it has built everywhere excepted sparc ... what arch do you use?
[05:07] <seb128> Zdra: ok, good :)
[05:08] <mdke> Spads: got a mo quickly?
[05:09] <Spads> mdke: Sure, what for?
[05:12] <Zdra> seb128: bug-buddy works after the upgrade, thanks :)
[05:12] <seb128> np :)
[05:33] <mjg59> rodarvus: Around?
[05:33] <allee> hi, updating edgy: volumeid, idev initramfs-tools update /boot/initrd.img but only for the running -686 kernel, not the also installed -386 kernel.  Somehow this seem to be wrong
[05:33] <Zdra> when I "apt-get source nautilus" are ubuntu's patch in debian/patches applied automatically ? Or should I apply them myself ?
[05:34] <seb128> Zdra: you have to apply them
[05:34] <mjg59> Zdra: They get applied at build time, not extraction time
[05:34] <seb128> Zdra: you get the upstream source and a debian dir, the patches are applied when building the package
[05:34] <Zdra> seb128: ok so https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/54162 is an ubuntu bug
[05:34] <Ubugtu> Malone bug 54162 in nautilus "Crash when DnD bookmarks in places sidebar" [Untriaged,Unconfirmed]  
[05:34] <seb128> Zdra: "debian/rules apply-patches" if you want to just apply them
[05:35] <seb128> Zdra: if you say so
[05:35] <Zdra> 06_documents_place.patch --> has to be updated
[05:36] <hungerW> Was gtk2-engines-* removed in edgy or are they just not up to date yet? apt wants to remove them when updating gnome-themes at the moment.
[05:36] <seb128> Zdra: API change?
[05:36] <iwj> mvo: Will your dist-upgrader be able to arrange to upgrade dpkg first (or nearly first) during dapper -> edgy upgrades ?
[05:36] <dholbach> hungerW: it should install gtk2-engines
[05:36] <Zdra> seb128: I made some changes in nautilus-places-sidebar.c for DnD of bookmarks
[05:37] <dholbach> hungerW: ubuntu-desktop will pull it in instead
[05:37] <seb128> -add_place (GtkListStore *store,
[05:37] <seb128> +add_place (NautilusPlacesSidebar *sidebar,
[05:37] <seb128> right
[05:37] <Zdra> I'm trying to update the ubuntu's patch to see if I can solve the problem
[05:37] <seb128> that's what I call and API change :p
[05:37] <hungerW> dholbach: Yep and it wants to deinstall gtk2-engines-clearlook and lots of others.
[05:37] <mvo> iwj: not right now, but if that is a requirement it could be added 
[05:37] <dholbach> hungerW: that's ok, they were merged
[05:37] <tseng> removnig gtk2-engines wont break anything for now
[05:37] <iwj> mvo: OK, yes, it will be a requirement.  So that I can tell people to start using Breaks.
[05:37] <seb128> Zdra: sidebar->store replaced by "sidebar" then?
[05:37] <tseng> lots of nice themes left around
[05:37] <iwj> mvo: Thanks.
[05:38] <mvo> iwj: ok, please file a but about it and give it some priority - otherwise I may forget about it
[05:38] <iwj> Willdo.
[05:39] <seb128> Zdra: what version of Ubuntu do you use (does it apply to dapper too?)? 
[05:39] <Zdra> seb128: no the change was commited to nautilus 2.15.90
[05:39] <Zdra> in upstream
[05:40] <Zdra> see upstream bug linked in my report on lp
[05:40] <seb128> Zdra: ok, thank you, I'm going to replace "sidebar->store" by "sidebar" now, that's the correct fix, right?
[05:41] <Zdra> seb128: it should fix, but wait I'm reading it more carefully to be sure there is nothing else to change... sidebar->store may be replaced by sidebar->filter_model in some places
[05:42] <seb128> ok
[05:42] <bddebian> Holy crap, there is a 30K difference in orig.tar.gz between Debian and Ubuntu for kiki
[05:45] <Zdra> seb128: ok for me, just replace sidebar->store by sidebar in add_place calls
[05:46] <bddebian> sladen: I know that, I'm just trying to figure out what to do about the SHA1 sums mismatch
[05:46] <sladen> bddebian: oh, orig.tar.gz ;  how does an md5sum of the /unpacked/ contents compare?  eg.  gunzip -cd foo.orig.tar.gz | md5sum
[05:47] <seb128> Zdra: thank you for pointing it!
[05:48] <bddebian> sladen: Compare in what way?  The md5sums are different, if that is what you are asking
[05:48] <Zdra> np
[05:49] <sladen> bddebian: I'm asking the md5sums of the /uncompressed/ contents.
[05:49] <bddebian> sladen: I know
[05:50] <bddebian> bdefreese@bdubuntu1:~/edgy/kiki$ gunzip -cd kiki_0.5.6.orig.tar.gz | md5sum
[05:50] <bddebian> ff536c386278040fd51dba12c75621b0  -
[05:50] <bddebian> bdefreese@bdubuntu1:~/edgy/kiki$ gunzip -cd ubuntu/kiki_0.5.6.orig.tar.gz | md5sum
[05:50] <bddebian> 2150bc6d2e3b5f21ecc63674cf751d8e  -
[05:50] <sladen> bddebian: if the tarball has been repacked, then the result file will likely be a differing size
[05:50] <sladen> bddebian: funky.  What happens if you unzip both of them and do a diff -r between them?
[05:50] <iwj> mvo: OK, I give up, what's the package name ?
[05:51] <bddebian> sladen: Thanks, give me a sec
[05:52] <Kamion> dholbach: gnome-keyring-manager promoted
[05:52] <dholbach> woohoo! :)
[05:53] <bddebian> Heya dholbach
[05:53] <dholbach> hey Barry
[05:53] <mvo> iwj: file it against update-manager please
[05:59] <doko> pitti: do you want to get a UVF for blender and merge that one? python policy ...
[06:00] <pitti> doko: oh, hm, if we need it
[06:01] <pitti> doko: I don't have time for merging now, but I can do it this week
[06:01] <doko> pitti: no haste, would be nice ...
[06:02] <bddebian> sladen: OK, now that's freaky:
[06:02] <bddebian> bdefreese@bdubuntu1:~/edgy/kiki/temp$ diff -r debian/kiki-0.5.6.orig ubuntu/kiki-0.5.6.orig
[06:02] <bddebian> Only in ubuntu/kiki-0.5.6.orig: kiki-0.5.6
[06:02] <bddebian> bdefreese@bdubuntu1:~/edgy/kiki/temp$
[06:03] <sladen> bddebian: what's in that file?  has somebody unpackaged the package inside itself?
[06:03] <pitti> YAY @ cups
[06:03] <iwj> Oh, up_date_ not up_grade_.
[06:04] <iwj> And there's me searching in LP for `upgrade' and getting >200 hits.
[06:05] <bddebian> sladen: Yep, in the ubuntu version there is kiki-0.5.6.orig/kiki-0.5.6
[06:09] <sladen> bddebian: if in doubt, do a fresh upload with the .orig.tar.gz from debian rediff it
[06:11] <bddebian> sladen: That's what I did but it fails so I am going to upload with our orig.tar.gz but the diff.z and .dsc from Debian.  That is correct right Kamion?
[06:13] <sladen> bddebian: I would guess that's the opposite way around?
[06:14] <bddebian> sladen: 
 bddebian: well, you can't get the Debian .orig.tar.gz in the archive; we only ever have one file with a given name
 bddebian: so you need to compare the Debian and Ubuntu .orig.tar.gzs
 bddebian: it may well be that there are no interesting changes, and the upload will do just fine with the Ubuntu .orig.tar.gz
[06:19] <ogra> dholbach, ubuntu-artwor split ? whats the other package ? 
[06:19] <ogra> *artwork
[06:19] <dholbach> ogra: they're in NEW
[06:19] <dholbach> ogra: the others will be named: edgy-community-wallpapers edgy-gdm-themes edgy-session-splashes edgy-wallpapers gray-theme human-cursors-theme human-gtk-theme human-icon-theme human-theme industrialtango-theme legacyhuman-theme outdoors-theme resilience-theme silicon-theme
[06:20] <ogra> ugh ... do i need to reflect that in edubuntu-artwork ? 
[06:20] <dholbach> ogra: that's your decision
[06:20] <ogra> ok, then its fine ...
[06:20] <dholbach> your the package maintainer :)
[06:20] <dholbach> s/your/you're
[06:20] <ogra> even though i need to know what is in wich package :)
[06:21] <ogra> but i'll dig through :)
[06:21] <dholbach> once they're in the archive, i'll link the branches to the packages
[06:21] <Kamion> zul_: at some point, could you convert xen-3.0 to the new Python policy, please? (Thoough I've accepted the binaries in the meantime.)
[06:21] <dholbach> they're all in bzr in launchpad already
[06:22] <ogra> i wonder if using the release name is such a good idea ... that forces us to have a new set of packages in the next release in any case ...
[06:22] <dholbach> ogra: that will give us the chance to offer people "dapper-artwork" if they like it better
[06:22] <Kamion> I agree, that seems a dubious design decision
[06:22] <dholbach> ogra: that was a common request
[06:22] <ogra> (but this time you're the ackage maintainer indeed ;) )
[06:22] <ogra> *package 
[06:23] <Kamion> can't we have distinct names that aren't release names?
[06:23] <ogra> s/edgy/default/ ?
[06:23] <dholbach> hmhmhmhmhm, that'd mean inventing package names, hm
[06:24] <ogra> you could have an edgy artwork metapackage with a versioned dependency ...
[06:24] <Kamion> ogra: no, that would mean having to rename default to something else in edgy+1 and introduce a new default
[06:24] <ogra> Kamion, yes, thast the point
[06:24] <ogra> *thats
[06:25] <ogra> i'm guessing we'll have new default artwork in edgy+1
[06:25] <Kamion> ogra: seems undesirable
[06:25] <Kamion> I'd prefer not designing something that requires packages to be renamed every release
[06:26] <Kamion> introducing new names is one thing, always having to rename the old thing out of the way first is another
[06:26] <ogra> thats why i said default-{wallpapers,session-splashes,etc}
[06:26] <ogra> why do yu need to renale ? 
[06:26] <ogra> *rename
[06:26] <ogra> ubuntu-artwork wasnt renamed since warty and always contained the default...
[06:27] <Kamion> we've never kept the old artwork around before though, at least not in separate packages
[06:27] <ogra> right 
[06:27] <Kamion> I have no objection to there being a package that depends on whatever the current default artwork is, obviously
[06:27] <ogra> so the plan is to kepp the old ones ?
[06:27] <ogra> *keep
[06:27] <Kamion> that's what dholbach said
[06:27] <dholbach> ok, so you suggest, i drop the 'edgy-' bit and preserve changes in a 'dapper-*' package once I do the change?
[06:28] <Kamion> I don't like having release names in packages at all, personally
[06:28] <dholbach> hm
[06:28] <Kamion> what's in edgy-*?
[06:28] <dholbach> i wanted to server the goal of still "having the old artwork" - since some people wanted to have that.
[06:28] <Kamion> is it just dependencies on the current default, or does it have artwork in it?
[06:29] <dholbach> it has artwork
[06:30] <Kamion> is there no way to give that collection of artwork a name?
[06:30] <Kamion> or is it really just "The Edgy Artwork"?
[06:30] <Kamion> if the latter, I guess edgy-* would be ok, I'd reluctantly withdraw my objection
[06:31] <dholbach> it is the edgy artwork, there was no 'meta name' given to it - ok, there was the 'Human look', but the community artwork stuff wouldn't qualify as Human, and I'm not sure that the edgy artwork will not be 'Human', even if it looks different
[06:31] <Kamion> ok, I see
[06:31] <dholbach> I'm happy for suggestions and not insisting on the packaging names, not all.
[06:33] <ogra> ..." but the community artwork stuff wouldn't qualify as Human" ...
[06:33] <ogra> call it inhuman then :P
[06:34] <ogra> actually shouldnt we just use release numbers and avoid the working names ? 
[06:34] <ogra> egdy wallpapers .... the nervous backgrounds :)
[06:35] <dholbach> that's fun, if we delay a release again ;)
[06:35] <ogra> yeah, indeed
[06:35] <bluefoxicy> I have a very strange question.  How in the crap does exim keep getting installed
[06:36] <bluefoxicy> I keep removing it (it never says anything depends on it) and it just comes back on an upgrade several weeks later.
[06:42] <mdke> bluefoxicy: likely you have something which requires an MTA. Best try #ubuntu for questions like that though
[06:44] <bluefoxicy> mdke:  apparently I don't because I can just remove it and it doesn't complain about other packages.
[06:44] <bluefoxicy> (I've already removed it)
[06:44] <Spads> are you maybe removing the metapackage only?
[06:45] <bluefoxicy> 'exim' seems to ask to remove undelivered mail when removed and also removes /etc/cron.d/exim
[06:45] <ogra> dholbach, gtk2-engines "Resynchronized with Debian, no Ubuntu changes." means it doesnt have a "Provides gtk2-engines-clearlooks" ?
[06:45] <Spads> bluefoxicy: dpkg -l 'exim*' and remove anything you don't want
[06:46] <Spads> bluefoxicy: but yeah, #ubuntu is better for this
[06:46] <bluefoxicy> Spads:  none installed.
[06:46] <bddebian> Yeah, it worked
[06:46] <bluefoxicy> Spads:  yeah, I'd ask in Ubuntu except nobody there is going to tell me why apt just decides "let's also install this new package on an 'upgrade', and not say it's new"
[06:47] <ogra> bluefoxicy, still, this isnt a support channel (see topic ;) )
[06:47] <bluefoxicy> ogra:  nods.  I'll come back when apt spouts half of universe for no reason then.
[06:47] <desrt> pitti; ?
[06:47] <ogra> ogra, come back if you have a fix for the prob and provide a patch ;)
[06:47] <ogra> err
[06:47] <bddebian> hehe
[06:48] <ogra> s/ogra/bluefoxicy/ (indeed)
[06:48] <desrt> pitti; you probably want to look at https://launchpad.net/distros/ubuntu/+source/openssh/+bug/54180
[06:48] <Ubugtu> Malone bug 54180 in openssh "[rfe]  sshd ought to support 'none' cipher" [Untriaged,Unconfirmed]  
[06:48] <bluefoxicy> ogra enjoys talking in third person, and should write man pages so that he can write about himself in the AUTHORS section  :)
[06:49] <ogra> yay
[06:49] <Kamion> desrt: me
[06:49] <Kamion> meh
[06:49] <Kamion> that's an ancient bug which upstream is not interested in doing
[06:49] <dholbach> ogra: they were merged in Debian. There are no Provides there.
[06:49] <desrt> Kamion; i know upstream isn't interested
[06:49] <desrt> Kamion; i was hoping for a vendor patch
[06:50] <Kamion> re bug, huh? it's not a matter of enabling it, it needs non-trivial code last I checked
[06:50] <ogra> dholbach, i talked with seb128 about it ... but i can change the ltsp deps ... its just a little unfortunate that i have to install all of them on a extreme low end system
[06:50] <desrt> Kamion; the current situation forces people to do much less secure things.... like xhosts +
[06:50] <desrt> Kamion; last time i enabled cipher none it was a switch-flip
[06:50] <Kamion> blowfish is fast enough for most purposes
[06:50] <Mithrandir> ogra: uh, are you on crack?
[06:51] <bddebian> hehe
[06:51] <ogra> Mithrandir, who needs that ? in times of ssh X forwarding anyway :)
[06:51] <Kamion> desrt: see Michael Stone's comment in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=13389
[06:51] <desrt> ogra; people who want performance
[06:52] <Kamion> (I realise there's a patch there)
[06:52] <ogra> desrt, blowfish isnt bad ... we run a full ltsp implementation with it :)
[06:52] <Kamion> (but it's not just a switch-flip and I'd be surprised if it still applied verbatim)
[06:52] <Mithrandir> : tfheen@thosu ~ > xhost +SI:localuser:test
[06:52] <Mithrandir> localuser:test being added to access control list
[06:52] <Mithrandir> : tfheen@thosu ~ > sudo -u test xdpyinfo
[06:52] <Mithrandir> Password:
[06:52] <Mithrandir> name of display:    :0.0
[06:52] <desrt> hmm.  was a switch-flip back in the day.
[06:52] <Mithrandir> etc
[06:52] <desrt> damn upstream ssh.  those cats are getting catty
[06:53] <Kamion> desrt: I suspect that "back in the day" was SSH1 protocol
[06:53] <Kamion> SSH2 is completely different
[06:53] <desrt> you're probably right
[06:55] <Kamion> desrt: IIRC one of the concerns about none is that it causes authentication to happen in plaintext too
[06:58] <pitti> re
[06:58] <Kamion> which is not what everyone expects
[06:58] <bddebian> wb pii
[06:58] <bddebian> Err pitti
[06:58] <pitti> desrt: hmm
[06:59] <janimo> mvo: hi, which is the best g-a-i bzr branch to base new work on? the ones in LP don;t seem up-to-date
[07:02] <Riddell> carlos: what's your answer to this? http://lists.kde.org/?l=kde-i18n-doc&m=115313298518227&w=2
[07:02] <Riddell> how do ubuntu translation teams find out about their upstream
[07:02] <mvo> janimo: please use http://people.ubuntu.com/~mvo/bzr/gnome-app-install/gai--main/
[07:03] <ogra> heh, you sill have bazaar urls :)
[07:03] <carlos> Riddell: let me read the email...
[07:04] <carlos> Riddell: https://launchpad.net/products/rosetta/+bug/87
[07:04] <Ubugtu> Malone bug 87 in rosetta "Some upstream translators asked for links to GTP, KTP and GNUTP" [Medium,Confirmed]  
[07:06] <carlos> Riddell: so no, we don't have yet implemented
[07:06] <Keybuk> *sigh*
[07:06] <Keybuk> it really occurs that autoconf/make/etc. need to die
[07:06] <carlos> Riddell: and yes, we should
[07:06] <Riddell> carlos: good enough answer though, thanks
[07:06] <Keybuk> KB of foolery just to install a png in the right place
[07:08] <Keybuk> Riddell: yeah, but they replaced it with unsermake
[07:08] <Riddell> Keybuk: changed to CMake now (in trunk)
[07:08] <Keybuk> cmake also replaces make. no?
[07:08] <Keybuk> which seems foolish
[07:09] <hub> it does
[07:09] <hub> replace make
[07:09] <hub> cmake is aimed at providing a consistent and configurable build system
[07:10] <Riddell> hub: does it generate Makefiles?
[07:10] <Riddell> doesn't
[07:11] <Keybuk> see, that bit I don't understand
[07:11] <Keybuk> make is well understood, flexible and *works*
[07:11] <doko> infinity, cprov, whoever: please requeue openoffice.org 2.0.3-3ubuntu3 on amd64, sparc and powerpc; the b-d's should be in place
[07:11] <hub> Riddell: you probably know better than I do
[07:11] <hub> maybe I'm wrong
[07:11] <Riddell> hub: nope, I've not looked at trunk :)
[07:11] <hub> hold on, I have trunk here
[07:12] <Riddell> but as far as I know CMake generates Makefiles and uses normal make
[07:12] <hub> "CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice."
[07:12] <Keybuk> I've always thought the perfect system would be one written in make
[07:12] <hub> so yes
[07:13] <Keybuk> so you don't need to generate anything
[07:13] <hub> Keybuk: we had a build system entirely based on GNU Make in AbiWord. A huge PITA to maintain
[07:13] <hub> Keybuk: we now use automake :-)
[07:13] <hub> and I have ported it 3 or 4 times
[07:13] <Keybuk> hub: why would it be a PITA?
[07:13] <Keybuk> you can implement automake using GNU make
[07:14] <Keybuk> the only difference is the need to include automake.mk or something at the top
[07:14] <hub> Keybuk: try to build on anything that is not linux
[07:14] <Keybuk> hub: who cares about building on anything that doesn't have GNU make?
[07:14] <Keybuk> seriously, when did you last bother with AIX 2 ?
[07:14] <hub> Keybuk: in our case we did. We required GNU Make
[07:14] <Keybuk> the world today is Linux, BSD and Solaris
[07:14] <ogra> Keybuk, /dev/evms/hda3         46G  1,8G   42G   4% /home are you aware of this ? (i dont use evms, seems a UUID problem)
[07:14] <Keybuk> ogra: yes, and I don't care <g>
[07:14] <ogra> oh ? 
[07:14] <ogra> why that ? 
[07:15] <hub> Keybuk: the world today is a melting pot of everything
[07:15] <Keybuk> I know nothing about evms, someone who does can fix that
[07:15] <Keybuk> hub: disagree
[07:15] <hub> Keybuk: AIX is painful anyway
[07:15] <hub> Keybuk: 95% of the world PC run MSFT Windows
[07:15] <hub> do we bother?
[07:15] <Keybuk> I'd disagree with that 95%
[07:15] <cprov> doko: ia64 as well ?
[07:15] <ogra> Keybuk, i dont think thats an evms problem :)
[07:16] <Keybuk> ogra: it is
[07:16] <ogra> ogra@edubuntu:~$ grep /home /etc/fstab 
[07:16] <ogra> UUID=7c24e63d-e8f7-4738-93f5-a63edd2c641a /home ext3 defaults 0 2
[07:16] <ogra> there is no /dev/evms but a UUID ...
[07:16] <sivang> hub: AIX is not too much painful, really, it's more of a bit crippled version of Linnux
[07:16] <HiddenWolf> crimsun: got a sec?
[07:17] <hub> sivang: the biggest problem is usually do get you hands on one ;-)
[07:17] <hub> sivang: I have seen worse: BOSX
[07:17] <hub> the compiler couldn't even compile gzip
[07:17] <doko> cprov: yes, please
[07:18] <sivang> hub: you should have grabbed the AIX Linux Toolbox CD, nothing needs to be compiled from source, almost :p
[07:18] <dholbach> TheMuso: you know if java-access-bridge is something cool for the a11y team? it was on gnome's release list
[07:18] <cprov> doko: sparc just failed again -> https://launchpad.net/+builds/+build/231427
[07:18] <hub> sivang: I haven't touched AIX since 1995
[07:18] <pitti> lamont: here?
[07:19] <doko> cprov: hmm, then Riddell's analysis was wrong. will have a look ...
[07:19] <cprov> doko: right, amd64 and powerpc failed too ... bad day 
[07:20] <sivang> hub: My last time was about 2 months ago, but let's end this discussion about it now or move to PM :-)
[07:22] <hub> sivang: sure. Ubuntu does not run on top of AIX, so not an issue :-)
[07:22] <sivang> hub: well, it actually could (RHEL and SUSE do).
[07:29] <zul> hi
[07:34] <doko> cprov: please retry, when mesa-common-dev 6.5.0.cvs.20060725-0ubuntu1 is in the archive
[07:35] <cprov> doko: will check when the current cron.daily finishes
[07:35] <cprov> doko: in 5 minutes or so
[07:35] <doko> thanks
[07:37] <zul> thanks archive admins :)
[07:37] <ogra> zul, so we have xen now ? 
[07:38] <zul> its in the archive as far as i can tell
[07:38] <Kamion> yes
[07:38] <ogra> yay
[07:38] <Kamion> except not xen-source-2.6.16 binaries yet
[07:38] <ogra> any chance we'll get it for the current kernel at some point ? 
[07:39] <zul> hehe...
[07:39] <zul> thats alot of work right now which has to be started again..
[07:39] <zul> ogra: xen has its own smp_alt which is different from our own
[07:40] <ogra> meh
[07:40] <zul> and we have to make sure it doesnt break anything...
[07:40] <zul> so maybe not for edgy
[07:41] <ogra> well, at least we have it :)
[07:45] <zul> amd64 support for next release
[07:58] <cprov> doko: mesa was already in the archive (at least wasn't touched during the last publisher run)
[08:08] <madduck> RFC: "Ubuntu, an immensely successful Debian derivative, completely abandoned the notion of package ownership by maintainers and instead practices completely open collaborative package maintenance, meaning that any of the developers are authorised to make changes to any package, on the basis that the developer will act responsibly in each case and confer with colleagues when faced with a non-trivial problem." -- would you say this adequate
[08:09] <madduck> (sorry for the long post, hope it wasn't cut off)
[08:09] <Burgwork> madduck, I would avoid the use of abandoned, as it sounds negative
[08:09] <madduck> abolished?
[08:10] <madduck> have you got a suggestion?
[08:10] <Burgwork> "practices completely open collaborative package maintenance, rather than specific package ownership by single maintainers"
[08:10] <madduck> my goodness, now i notice how it's one big run-on sentence. damn german me.
[08:10] <madduck> Burgwork: consider it done.
[08:11] <Burgwork> madduck, cheers
[08:11] <Burgwork> oh, and you need a few commas in there
[08:11] <madduck> lemme paste the new thing in a sec, then i'd appreciate if you'd help me. :)
[08:11] <madduck> any other comments?
[08:12] <madduck> (anyone?)
[08:13] <tseng> I can help you rewrite it
[08:13] <tseng> give me a moment
[08:13] <madduck> how's this? http://rafb.net/paste/results/5WxiiV67.txt
[08:13] <johndomero> Hello, I have been working with preseeding the Debian-Installer with Dapper, and I am having some difficulties with "base-config base-config/late_command"
[08:13] <tseng> madduck: not great :)
[08:13] <madduck> tseng: :(
[08:13] <tseng> one moment i need to get it in gedit or so
[08:13] <tseng> it really cant work in one sentence is all
[08:14] <madduck> but i put a colon in there. :)
[08:14] <johndomero> I made an auto-installation CD with Breezy, and "base-config base-config/late_command" worked well; but it refuses to run under Dapper. Has "base-config base-config/late_command" been depreciated in favor of something else?
[08:14] <tseng> your content is very good
[08:15] <ogra> tseng, sure it works in one sentence (in german though)
[08:15] <tseng> ogra: yep :)
[08:15] <ogra> :)
[08:15] <madduck> ogra: non-germans just don't have the mental capacity. :)
[08:15] <epx> >D
[08:15] <ogra> madduck, yeah
[08:16] <madduck> phone...brb
[08:17] <Kamion> johndomero: yeah - use preseed/late_command and 'chroot /target ...' to do stuff in the installed system
[08:17] <Kamion> johndomero: base-config's dead, so base-config/late_command no longer works
[08:17] <Kamion> johndomero: if you give me a little more detail about what you're doing then I'll be happy to try to give you more detailed advice
[08:18] <tseng> madduck: http://pastebin.ca/101100
[08:18] <johndomero> Kamion: The Dapper installation documentation from installation-guide-i386 (file:///usr/share/doc/installation-guide-i386/en/apbs04.html) still claims that "base-config base-config/late_command" exists.
[08:18] <tseng> madduck: this isnt perfect but it breaks it down into bits digestible by us stupid americans
[08:18] <tseng> in the last sentence
[08:19] <tseng> fact should be changed to something less firm
[08:19] <johndomero> Kamion: Could this documentation be updated to reflect this change? ;-)
[08:19] <tseng> but expectation sounds crap there.
[08:19] <johndomero> Kamion: I appreciate your help.
[08:19] <Kamion> johndomero: huh, I thought I'd caught that one
[08:19] <Kamion> sorry about that
[08:19] <Burgwork> hmm?
[08:20] <Kamion> yes, you're quite right - it will probably be cleared up when I merge installation-guide from Debian in edgy, but I'll file a bug to make sure I remember
[08:20] <tseng> comma between open and collaborative is really grammatically correct, too.
[08:20] <tseng> i have to run for a bit.
[08:20] <johndomero> Kamion: What was the reason for depreciating it? Second of all, are there any limitations in using the chroot method with d-i late command?
[08:21] <Kamion> johndomero: it was replaced by doing everything in a single stage, which is simpler, easier to maintain, and less buggy
[08:22] <Kamion> johndomero: about the only awkwardness is that debconf interaction from inside the chroot (either using debconf directly, or installing packages which might use debconf) is a little tricky
[08:22] <Burgwork> madduck, when you want me to look at it again, just ping me
[08:22] <Kamion> johndomero: there's an 'in-target' program that you can use in place of 'chroot /target' which knows how to deal with that
[08:22] <madduck> tseng: very nice. thank you.
[08:23] <johndomero> Kamion: Where can I get the source for Ubuntu's Debian-Installer? I am working on a deployment scheme for a large university, and I am having to reference things a lot.
[08:23] <Kamion> note that it also does stuff like diverting away start-stop-daemon, which catches some people by surprise
[08:23] <johndomero> Kamion: How does this 'in-target' work?
[08:23] <Kamion> johndomero: in-target> apt-get source debian-installer-utils, it's all in there
[08:23] <allee> ahhh preseeding! My tonight TODO item ;) Some weeks before dapper I preseeded a dozend hosts successfully.  Now with a new set of hosts, install hangs accessing the archives (hosts are in a priv. net.  So I preseeded my apt-proxy cache)
[08:23] <doko> Kamion: are some mesa binaries in NEW?
[08:23] <Kamion> johndomero: the installer is made up of a lot of components, and we don't have a single revision control repository for them all (yet, I'm working on that)
[08:24] <Kamion> johndomero: for the time being, you need to find which component you're interested in, and 'apt-get source' that
[08:24] <johndomero> Kamion: I appreciate your help. It has been more useful than you probably realize. ;-) So little of this information is documented online.
[08:24] <Kamion> doko: not as far as I can see
[08:25] <Kamion> doko: the NEW queue is publicly-viewable - https://launchpad.net/distros/ubuntu/edgy/+queue
[08:25] <madduck> Burgwork, tseng: it got a little long now (even before tseng reworked it), so I think I'll just stick with something like http://rafb.net/paste/results/eQ3D1t87.txt -- this is all in the introduction anyway, i'll dig deeper in the following chapters...
[08:25] <doko> Kamion: nice, didn't knew that
[08:25] <Kamion> doko: it is possible that Scott processed it recently - the queue is emptier than when I last checked
[08:26] <Kamion> doko: what version?
[08:26] <allee> johndomero: you happen to know how to turn off security archive via preseeding?
[08:27] <Kamion> doko: https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=3&queue_text=mesa&start=20 - it looks like it's being processed at the moment
[08:27] <Burgwork> madduck, just a question, before I comment further: what is the target audience?
[08:27] <Kamion> allee: 'd-i apt-setup/security_host string '
[08:27] <Burgwork> Kamion, should I bother filing a UI bug on that queue?
[08:28] <doko> Kamion: mesa-common-dev is needed in version 6.5.0.cvs.20060725-0ubuntu1
[08:28] <Kamion> Burgwork: it's not my responsibility, so I don't know - go ahead I guess
[08:28] <Burgwork> can do
[08:28] <Kamion> doko: I think it got uploaded *just* after the publisher run before this one
[08:28] <Kamion> doko: and is currently being published
[08:28] <madduck> Burgwork: academic. this is a revised phd proposal. so probably noone except those unfortunate examiners. :)
[08:28] <doko> ahh, ok
[08:28] <Kamion> just after the previous run started, I mean
[08:29] <Burgwork> madduck, ah, ok. Then they can deal with the technical language
[08:29] <allee> Kamion: thx I thought I tried this.  Maybe this then not the reason for by problem.  I try it again
[08:29] <madduck> Burgwork: they'll refuse it if I talk plainly, even. been there, done that.
[08:29] <Burgwork> Kamion, that is part of soyuz, no?
[08:29] <doko> Kamion: I do have the impression that the processing of binaries is slower (compared to what we had for dapper), i.e. the time from upload to availability in the archive (without considering the build time)
[08:29] <Kamion> johndomero: yeah, documentation for people who are kind of half way in between users and developers is a tricky area that we're kind of weak on in the installer
[08:29] <Kamion> Burgwork: yes
[08:30] <Kamion> doko: it's not any slower compared to dapper, but it's slower compared to breezy
[08:30] <Kamion> doko: mesa/i386 managed to hit the worst case this time round, by bad luck
[08:30] <Kamion> doko: also, the buildds were stalled for a long time today due to DNS problems inside the DC
[08:30] <doko> Kamion: or I'm more impatient ;)
[08:30] <Kamion> but there's nothing systemic that I'm aware of to make binary processing generally slower than dapper
[08:31] <Kamion> allee: depends where it hangs - you might need to preseed mirror/* too
[08:31] <johndomero> Kamion: in-target will take all of $* and pass it through to the safe chroot?
[08:32] <Kamion> madduck: is it worth mentioning the distinction between "core developers" and "developers" at that point, or is that too much detail?
[08:32] <Kamion> madduck: (core developers => unrestricted upload, developers => universe and multiverse components only)
[08:32] <madduck> Kamion: probably too much detail. I am really only (ab)using Ubuntu as an extreme here.
[08:32] <Kamion> johndomero: yes
[08:32] <Kamion> log-output -t in-target chroot /target "$@" || ERRCODE=$?
[08:32] <bddebian> What's madduck whining about now? ;-)
[08:32] <Kamion> (there's lots of setup/cleanup around that, but ...)
[08:33] <bddebian> heh
[08:33] <madduck> Kamion: my work is still about Debian. i just wanted to make sure i got the Ubuntu description right.
[08:34] <bddebian> madduck: And here I thought you had come over to the Light side :-)
[08:34] <Kamion> johndomero: (bug 54185 is the base-config doc bug, in case you want to subscribe to it)
[08:34] <Ubugtu> Malone bug 54185 in installation-guide "still talks about base-config" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54185
[08:34] <madduck> bddebian: there's no dark side of the moon really, as a matter of fact, it's all dark.
[08:35] <bddebian> Oh, Floyd.. nice
[08:36] <madduck> Gerry Driscoll actually. :)
[08:36] <bddebian> Yeah, well..
[08:37] <johndomero> Kamion: Where does one get the sources for the various udebs? Does this come debian-installer-utils?
[08:38] <Kamion> johndomero: no, debian-installer-utils builds some udebs but not all of them
[08:39] <Kamion> johndomero: unfortunately you sort of have to know the component name; doing 'find /cdrom/pool -name \*.udeb' on an Ubuntu CD and looking at the last directory name in each line of output can help
[08:39] <Kamion> (the last directory name is the name of the source package)
[08:40] <Kamion> udebs are like debs in most respects - they just don't follow Debian policy
[08:40] <Kamion> but they're still built from source packages in more or less the usual way
[08:41] <Kamion> it's not quite one-to-one from source packages to udebs, but most installer source packages build a handful of udebs at most, often only one
[08:54] <lfittl> madduck: ping
[08:54] <madduck> lfittl: boing?
[08:56] <neoxan> hi Seveas 
[09:04] <doko> cprov: mesa is now in the archive, please requeue the OOo builds (again)
[09:04] <cprov> doko: okay
[09:07] <cprov> doko: 4 archs reset (amd64, powerpc, sparc, ia64)
[09:08] <neoxan> hi Seveas 
[09:10] <gnomefreak> Keybuk: you got a sec?
[09:12] <Keybuk> gnomefreak: sure, what's up?
[09:12] <Keybuk> Kamion: wasn't me
[09:13] <gnomefreak> Keybuk: pm?
[09:13] <Keybuk> Kamion: well, mesa wasn't me -- I did do a NEW blitz recently
[09:13] <Keybuk> gnomefreak: it's the afternoon here, yes ?
[09:13] <gnomefreak> may i pm you for a sec? ;)
[09:13] <neoxan> gnomefreak, do you know why Seveas kicks me in every ubuntu channel and calls me an "loser and asshole"?
[09:13] <Keybuk> what does "pming" me involve?
[09:13] <neoxan> sry, if its offtopic in here
[09:13] <neoxan> :)
[09:14] <elmo> Keybuk: private-message
[09:14] <Keybuk> elmo: ahhh
[09:14] <gnomefreak> Keybuk: you r/msg ;)
[09:14] <Keybuk> duh
[09:14] <Keybuk> gnomefreak: right, sure :)
[09:14] <azeem> Keybuk: irc newb
[09:15] <Keybuk> azeem: I think it's more IRC oldb
[09:15] <neoxan> gnomefreak? :(
[09:15] <neoxan> nobody wants to help me
[09:16] <gnomefreak> ty :)
[09:16] <Keybuk> no probs
[09:16] <gnomefreak> that will hold us until k-line
[09:19] <rodarvus> mjg59, I'm here
[09:20] <Keybuk> uh, learns
[09:20] <elmo> keybuk: yeah, get out
[09:28] <ogra> ..."HAL 0.5.7.1 "Unmaintained piece of crap" is now available" ...
[09:29] <ogra> LOOOL
[09:29] <ogra> i wouldnt have expected him to go that far to ake it a release name :)
[09:29] <ogra> *make
[09:30] <hub> LOL
[09:30] <Keybuk> rofl
[09:31] <Keybuk> unfortunately, I have to agree with the kernel guys
[09:31] <ogra> baout h-d-m ?
[09:31] <ogra> *about
[09:31] <ogra> well, it works ...
[09:31] <hub> kernelslacker did put the emphasis on the number of files open by HAL
[09:32] <Keybuk> HAL is still a solution looking for a problem
[09:33] <mjg59> Keybuk: I think the problem it solves is pretty obvious
[09:33] <Keybuk> mjg59: which is?
[09:34] <elmo> abstracting hardware
[09:34] <mjg59> Obtaining information about available hardware from userspace
[09:34] <Keybuk> but that information is already available
[09:34] <mjg59> Through a variety of entirely different itnerfaces
[09:35] <mjg59> Which are all entirely Linux-specific
[09:35] <Keybuk> what's wrong with being Linux specific?
[09:36] <ogra> Keybuk, pingediping about a udev question ...
[09:36] <Keybuk> ogra: sure
[09:36] <mjg59> People want their software to work on mor ethan Linux
[09:36] <mjg59> Solaris has a not insignificant number of desktop users
[09:36] <Keybuk> mjg59: the most useful things that HAL could do, it doesn't ... it provides no write access to hardware, for exmaple
[09:36] <ogra> if you create the hdX devices on boot, you probe the disks for partitions or hw do you do that ? 
[09:36] <ogra> *how
[09:36] <mjg59> Keybuk: Increasingly, it does
[09:36] <Keybuk> ogra: umm, could you be a bit more verbose?
[09:37] <Keybuk> mjg59: it'd also be vaguely useful for HAL to hold information about devices that have been previously connected, but are not currently
[09:37] <ogra> Keybuk, the question i'm really after is, would it be possible to have udev tell me that there is a swap partition on a device 
[09:37] <mjg59> Keybuk: That's trivially layered on top of hal
[09:37] <ogra> and which device node that would be ...
[09:37] <Keybuk> mjg59: don't get me wrong ... I don't dislike HAL, or think it has no value ... I just think that it could be SO MUCH BETTER
[09:37] <Keybuk> ogra: yes
[09:37] <Keybuk> ogra: now, pitch your question better :p
[09:38] <mjg59> Keybuk: That's hardly the same thing as being a solution in search of a problem
[09:38] <Keybuk> do you mean "have udev automatically call swapon for any swap device" ?
[09:38] <mjg59> The problem that it deals with is clearly defined
[09:38] <vagrantc> Keybuk: we're looking to enable swap partitions on local drives for ltsp
[09:38] <mjg59> You may disagree with /how/ it attempts to solve that, but that's a separate objection
[09:38] <Keybuk> mjg59: yes, perhaps I was a little harsh there
[09:38] <ogra> Keybuk, we have code for local swap support in ltsp ... but that relies on probing all disks and all artitions ... which slows down boot significantly 
[09:38] <Keybuk> mjg59: I apologise
[09:38] <mjg59> Keybuk: No problem :)
[09:38] <ogra> my idea was to leave that to udev as its faser
[09:39] <Keybuk> ogra: right ... so, if you can say "here's a swap device on boot", what do you need to do
[09:39] <ogra> so we can autodetect if there is a swap partition and get rid of a config option
[09:39] <ogra> swapon indeed ;)
[09:39] <vagrantc> and mkswap
[09:39] <ogra> yeah probably too
[09:39] <Keybuk> SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="swap", RUN+="/sbin/swapon %k"
[09:40] <ogra> yay, thanks !
[09:40] <vagrantc> what versions of udev will that work with?
[09:40] <Keybuk> vagrantc: Ubuntu dapper and edgy
[09:40] <ogra> oh, right, that might be a prob for debian
[09:40] <vagrantc> right
[09:40] <Keybuk> who cares about Debian?
[09:40] <Keybuk> install the Ubuntu udev on it
[09:40] <ogra> Keybuk, vagrantc 
[09:40] <ogra> :)
[09:41] <vagrantc> well, i can see my time here is at an end.
[09:42] <ogra> i think you scared him :)
[09:42] <Keybuk> *shrug*
[09:42] <Keybuk> I spent ages making the Ubuntu udev work properly precisely so we wouldn't have to support the Debian broken version ;)
[09:43] <ogra> right ... but i'll need to look into if its possible in debian as well ...
[09:43] <Keybuk> oh, it's almost certainly possible, just with some pain
[09:43] <ogra> since we want to be distro independent with the future code of ltsp
[09:44] <Keybuk> you'd need to make sure that the upstream persistent rules are installed, and before yours
[09:44] <Keybuk> *shrug* I don't agree that's possible
[09:44] <Keybuk> or even desirable
[09:44] <Keybuk> you'll always need a distro-specific layer
[09:44] <ogra> "* vagrantc is more disappointed in the social aspect than the technical ones"
[09:44] <ogra> frm #ltsp :(
[09:45] <Keybuk> *shrug* that's just bullshit
[09:45] <Keybuk> if he wants to get support with Debian, he should go to Debian
[09:45] <ogra> well ... he cares about ltsp 
[09:45] <Keybuk> if he wants support with udev, they'll probably tell him to use Ubuntu instead of Debian
[09:46] <ogra> hes the best ltsp coder i have in debian and cares to make his stuff work in ubuntu ...
[09:47] <Keybuk> it's easy to make stuff work in Ubuntu
[09:47] <ogra> but i wouldnt have expected him being so thin skinned
[09:47] <Keybuk> I don't see how it's our problem that something is not as easy in Debian
[09:47] <ogra> the ude stuff was my idea ...
[09:47] <ogra> *udev
[09:48] <Keybuk> Debian is intrinsically difficult for things like this
[09:48] <Keybuk> Ubuntu is easy ... initramfs, udev, etc. all fit together properly
[09:48] <ogra> yep
[09:48] <ogra> *i* know that ... and he surely will make the code i submit work in debian ...
[09:49] <Keybuk> I'd like to see him go and ask the inverse question on #debian-devel
[09:49] <Keybuk> "how do I make this work in Ubuntu too"
[09:49] <Keybuk> I suspect he'll get a FAR ruder response
[09:50] <zul> heh
[09:54] <LaserJock> mjg59: I installed Dapper on my intel iMac, however it won't boot it. is there some special lilo trick?
[09:56] <Keybuk> heh, the GPL looks funny if you sort(1) it
[09:56] <ogra> heh
[09:56] <ogra> are you bored ?
[09:57] <elmo> why do I have a /usplash_fifo?
[09:57] <elmo> and I can rm it?
[09:57] <Keybuk> no, I'm processing the NEW queue
[09:57] <Keybuk> elmo: bug, yes
[09:57] <Keybuk> elmo: usually means you didn't have an initramfs
[09:57] <elmo> kthx
[09:57] <elmo> ah, yeah, i use to use monolithic
[09:58] <Keybuk> I was reading tar contents, then I amended my for/tar to extract the COPYING file to stdout ... but forgot to take out the | sort :p
[09:59] <ogra> hehe
[10:02] <Keybuk> excuse me a moment
[10:02] <Keybuk>      _ _           _ _                _     _
[10:02] <Keybuk>   __| | |__   ___ | | |__   __ _  ___| |__ | |
[10:02] <Keybuk>  / _` | '_ \ / _ \| | '_ \ / _` |/ __| '_ \| |
[10:02] <Keybuk> | (_| | | | | (_) | | |_) | (_| | (__| | | |_|
[10:02] <Keybuk>  \__,_|_| |_|\___/|_|_.__/ \__,_|\___|_| |_(_)
[10:02] <Keybuk> there, I feel better now
[10:02] <ogra> ouch
[10:02] <Keybuk> I've already rejected these once for having the wrong licence combination
[10:02] <Keybuk> and again, the same damned thing
[10:03] <gnomefreak> sweet
[10:03] <Keybuk> it could be an upstream tarball problem
[10:03] <Keybuk> the source claims LGPL, COPYING is the GPL
[10:10] <sivang> Keybuk: you can't go un-noticed like this, you know :)
[10:14] <Keybuk> sivang: hmm?
[10:15] <ogra> dholbach isnt online ... so he'll hardly notice it :)
[10:15] <ogra> sivang, ^^^
[10:15] <sivang> ogra: right, but it was enough to make me think something is wrong :-)
[10:15] <sivang> Keybuk: ^^
[10:35] <bluefoxicy> Keybuk:  you should hack up xchat so that it can highlight on ascii art.
[10:36] <Mez> bluefoxicy, or not ;p
[10:37] <bluefoxicy> Mez: http://rafb.net/paste/results/lwfjiz64.html
[10:38] <Mez> ;)
[10:40] <bluefoxicy> Also he's right.
[10:41] <bluefoxicy> "modifying or distributing the Program (or any work based on the mouse-clicks or menu items--whatever suits your program."
[10:41] <Keybuk> Mez: for?
[10:41] <Mez> Keybuk: for buggering off before i got a chance to swap keys with you
[10:42] <Keybuk> heh, they kicked everybody out
[10:42] <Keybuk> I didn't bring key stuff anyway
[10:42] <Keybuk> my passport is being replaced
[10:42] <Mez> Keybuk: you coulda come back at 8 :P
[10:42] <Mez> Keybuk: next time eh ? 
[10:42] <Mez> and /me slaps you again for the microphone comment
[10:42] <Keybuk> Mez: was too tired, too broke, and stuff
[10:43] <Mez> Keybuk: *shrugs* I know the feeling
[10:45] <sivang> Mez: where do you guys unmeet? :)
[10:46] <sivang> s/do/did/
[10:47] <Mez> divang: unmeet?
[10:47] <Mez> s/divang/sivang
[10:48] <Mez> sivang, we met @ LUG Radio Live 2006 (and at UBZ before that - and at LRL2005 before that)
[10:49] <sivang> Mez: a, what's LRL ?
[10:50] <Mez> LUG Radio Live
[10:50] <sivang> s/unmeet/almost-met/
[10:50] <Mez> sivang: we did meet - we just didnt sign
[11:57] <zul_> someone looking for me?