[12:09] <z\> tnx .
[12:13] <jdong> boy is archive.ubuntu.com slow today :-/
[12:23] <Kamion> jdong: we've been having a weekend + UK bank holiday after getting back from the sprint - cut us a *little* slack please :)
[12:23] <Kamion> jdong: it's Keybuk's archive day tomorrow, so I'm sure he'll catch up for you
[12:24] <jdong> Kamion: sorry, I wasn't trying to be rude/impatient.... this is really the first time I've worked with ubuntu-archive... just curious
[12:24] <Kamion> typically archive processing does not happen on weekends
[12:24] <jdong> I'm patient
[12:24] <Kamion> unless it's world-shattering urgent
[12:24] <jdong> but... it's a new version of k3b... it's gotta be world-shattering urgent :)
[12:24] <Kamion> we caught up on most things except syncs and some of the promotion/demotion details on Friday
[12:26] <lucas> infinity: ping
[12:26] <lucas> infinity: the status of ruby on powerpc hasn't changed. it has been broken for months now.
[12:27] <lucas> I can't do anything about it since it requires buildd access to investigate (the same packages work fine in debian)
[12:34] <z\> fabbione PING
[01:08] <bddebian> Howdy
[01:09] <shackan> z\, he's in vacation for two weeks, what are you looking for?
[01:11] <z\> shackan i have to talk with fabio about a possible bug.
[01:13] <z\> and i should to talk with fabio about my possible employment.
[01:13] <shackan> at canonical?
[01:13] <z\> at home 
[01:13] <z\> http://www.ubuntu.com/employment#head-ee181be4e2f101318f548b6e62a74711085e9224
[01:13] <z\> :D
[01:14] <shackan> oh
[01:15] <shackan> so you're a.. security expert?
[01:15] <z\> i work in this sector.
[01:15] <shackan> I see
[01:15] <z\> where ?
[01:16] <treitter> is there a "best practice" for a package that only _partially_ conflicts with another? (ie, overwriting one of its config files)?
[01:16] <grexk> hello everyone
[01:17] <treitter> I want to create a package that installs some config files in /etc, but I don't want to have to patch a million different packages, just to overwrite their default config files
[01:17] <z\> shackan sorry.. 
[01:17] <z\> but why u talk about me in english if u r italian ?
[01:18] <Burgwork> z\, because this is a mostly english channel?
[01:18] <treitter> I'll second Burgwork
[01:18] <z\> ok.
[01:18] <treitter> z
[01:19] <treitter> z\: I hope that doesn't sound like we're against people speaking their own language
[01:19] <crimsun> treitter: it's not allowed to just prance upon another's conffile.
[01:19] <z\> uhm, ok.
[01:19] <treitter> crimsun: of course. But is there any easier way?
[01:20] <LaserJock> crimsun: "prance"? I was thinking "clober" but you were more eloquent as usual
[01:20] <treitter> z\: but the downside of people speaking in another language is that other people who might want to participate might not be able to
[01:20] <crimsun> treitter: call a helper method to adjust the conffile owned by the package you're prancing upon
[01:20] <treitter> crimsun: in postinst?
[01:21] <crimsun> treitter: does the package [whose conffile is affected]  offer a means of adjusting its conffile?
[01:21] <treitter> crimsun: not sure. Where/how would it offer this means?
[01:23] <crimsun> treitter: section 10.7.4, Policy
[01:23] <treitter> crimsun: thanks! I'll check it out
[01:47] <desrt> someone ought to poke this bug: https://launchpad.net/distros/ubuntu/+source/openssl/+bug/57736
[01:47] <Ubugtu> Malone bug 57736 in openssl "HW engines are missing" [Untriaged,Unconfirmed]  
[01:51] <desrt> keybuk might be one such person
[01:51] <tseng> possibly.
[01:51] <desrt> Keybuk; i've found that you muck around with openssh from time to time.  are you also an openssl type?
[01:51] <Keybuk> err
[01:52] <Keybuk> I know how to connect the two bits together
[01:52] <desrt> that's a very strong no.
[01:52] <desrt> i think i'm confusing Keybuk with Kamion again
[01:52] <desrt> sorry.
[01:52] <Keybuk> yes
[01:52] <Keybuk> Kamion is the openssh maintainer
[01:53] <jdub> desrt: dude, you have met them in real life!
[01:53] <desrt> i have this problem when i talk to people on irc i often don't think about who they actually are
[01:54] <Keybuk> now, was desrt the short, fat, loud one?
[01:54] <Keybuk> or the tall, cute one with the long hair?
[01:54] <desrt> tall and with long hair, certainly
[01:54] <desrt> perhaps also loud
[01:54] <Burgwork> whiprush, you need to educate the Edubuntu people all about profiles, etc. As they are looking for stuff sabayon doesn't offer, but don't have a clear roadmap
[01:55] <desrt> Burgundavia was the cute one
[01:55] <whiprush> Burgwork: I can talk to ogra at the ltsp hackathon in a few weeks
[01:55] <Burgwork> desrt, not hard. Keybuk is the crazy one. Kamion is the sane and stable one
[01:55] <Burgwork> whiprush, excellent, but ogra isn't doing the work. LaserJock and cbx33 are
[01:55] <Keybuk> gee, thanks
[01:56] <whiprush> Burgwork: ok, you have a link to a spec or something?
[01:56] <Burgwork> edubuntu-dynamic-menus
[01:56] <whiprush> ta
[01:56] <LaserJock> whiprush: but I've had to totally redo the implementation
[01:56] <LaserJock> as sabayon hasn't worked out for what we'd like to do
[01:57] <tseng> Burgwork: you mean between releases Kamion is sane and stable
[01:57] <whiprush> the idea looks neat LaserJock 
[01:57] <tseng> Burgwork: i wouldnt anger him after his 15th cd build
[01:59] <Keybuk> Kamion is certainly more conservative than I
[01:59] <Keybuk> I wouldn't say he was either sane nor stable :p
[01:59] <Keybuk> unless he's a special kind of sane that's the opposite of insanity, rather than simply its abscence
[02:00] <LaserJock> and seems to play a mean Mao
[02:00] <jcole> i get this installing kubuntu -> /usr/share/debconf/confmodule: line 42: 3: Bad file descriptor
[02:00] <Burgwork> tseng, ineed
[02:00] <jcole> ctrl-alt-f2 and killing dpkg lets it continue
[02:01] <whiprush> upstart works for me on the X40 if you're looking for feedback
[02:01] <desrt> jdub; what kind of cash does the foundation have kicking around?
[02:02] <jcole> his is the offending line --> echo "$@" >&3
[02:02] <jdub> desrt: USD
[02:03] <desrt> er.  i meant more like the order of magnatude than the variety
[02:03] <Keybuk> whiprush: yeah, it has worked for everyone.  I'm quite shocked actually
[02:03] <desrt> *magnitude
[02:03] <Keybuk> the only thing I don't understand is why upstart is so much quicker at shutting down the machine than sysvinit
[02:03] <whiprush> heh
[02:03] <Keybuk> I worked out why it was faster at booting
[02:03] <jdub> desrt: do you really expect a real answer to that?
[02:03] <desrt> jdub; ya.  i do.
[02:04] <jdub> desrt: ok, your expectations are not in line with reality. :-)
[02:04] <desrt> the answer should be a solid "none" or otherwise an approximate amount
[02:04] <Keybuk> desrt: that number was public at the time of announcement
[02:04] <desrt> but in any case it should be public knowledge
[02:04] <Keybuk> google://ubuntu+foundation+dollars appears to give you the same answer multiple times
[02:04] <Keybuk> $10 M
[02:05] <desrt> oh crap.  not that foundation
[02:05] <desrt> the gnome on
[02:05] <gnomefreak> iirc it was 10 mil to ubuntu 10 mil to foundation at start
[02:05] <jdub> desrt: it is reported publically, but not generally discussed on random irc channels
[02:06] <desrt> same story for gnome too, i guess?
[02:06] <Keybuk> whiprush: is it faster at shutting down for you too?
[02:06] <jdub> desrt: i'm answering for gnome
[02:06] <desrt> gotcha.
[02:06] <desrt> so how do i find out?
[02:06] <jdub> desrt: i don't believe anyone here can answer for TUF
[02:06] <jdub> desrt: mail board-list
[02:07] <jdub> desrt: though you'll obviously get questions as to why
[02:07] <gnomefreak> gnome isnt really a non-profit org. so as to release that as public info is not a have to
[02:08] <sladen> Keybuk: did you do the upload so that upstart is now default as /sbin/init ?
[02:08] <whiprush> Keybuk: I can't tell either way, though I have not measured it.
[02:08] <Keybuk> sladen: not yet, still fiddling with the shutdown tool
[02:09] <Keybuk> deciding which of shutdown, halt, reboot, poweroff will be the "canonical" one and which are ubuntu-compat-sysv fodder
[02:09] <Keybuk> I vaguely feel that since reboot is the syscall, that one should be, but meh
[02:10] <sladen> Keybuk: make a new one called sys_reboot and overload that
[02:10] <Keybuk> eh?
[02:11] <LaserJock> whiprush: get my pm?
[02:11] <sladen> Keybuk: sys_reboot is the name of the syscall
[02:11] <whiprush> LaserJock: I responded, I think it's me not registering with freenode again
[02:11] <sladen> Keybuk: or "yes", I agree that reboot should be the canonical binary
[02:11] <LaserJock> whiprush: ah, well maybe #edubuntu real quick?
[02:11] <whiprush> sure
[02:12] <sladen> Keybuk: I think you should provide redhat style 'service' compatibility
[02:12] <tseng> sladen: /usr/bin/service ?
[02:12] <tseng> or sbin rather
[02:13] <sladen> tseng: yup.  the red hat jockeys love it;  it's also marginally more nice (as in "making it simpler for the user") than either type 'initctl' or 'etc/init.d/foo'
[02:14] <tseng> maybe we could make a vfs too
[02:15] <tseng> so they can cd to /etc/sysconfig/wtf/network/network-scripts/network-interfaces/maybe-stuff-here
[02:15] <jdub> /roflcopter/
[02:15] <Keybuk> sladen: how do you mean?
[02:15] <Keybuk> I'd vaguely figured on having /usr/sbin/start and /usr/sbin/stop
[02:16] <Keybuk> start apache
[02:16] <Keybuk> stop smoking
[02:16] <Keybuk> initctl is just a temporary thing
[02:17] <sladen> keybuk: start and stop are quite major pieces of namespace, especially when you add restart and reload
[02:17] <Keybuk> sladen: true, but then so is init
[02:17] <Keybuk> and I think once you have init, you get to be arrogant about your namespace
[02:17] <sladen> Keybuk: and especially if (as was talked about) 'start', 'stop', 'wankbadger' become an arbitary first parameter
[02:18] <Keybuk> "wankbadger" ?
[02:18] <sladen> Keybuk: the one I'd really like is MacOSX 'open'
[02:18] <bddebian> haha
[02:18] <Keybuk> open?
[02:18] <sladen> Keybuk: 'foobar' 'moo' 'crack' 'speeeeefial'
[02:18] <Keybuk> eh?
[02:19] <Keybuk> I'm clearly not following you here
[02:20] <sladen> Keybuk: Mac OSX (a modern Unix-based OS made by a company called Apple), has a command called 'open' that is performs what ever the equivalent of a double-click (eg. actually a mime-match) would be.  'open foldername' brings up the equivalent of nautilus, 'open foobar.mp3' brings up itunes, 'open moo.pdf' brings up the doc viewer
[02:20] <Keybuk> alias open=gnome-open
[02:20] <sladen> Keybuk: rocking.
[02:21] <Keybuk> I didn't follow the foobar, moo, crack, bit
[02:21] <sladen> Keybuk: $x
[02:21] <Keybuk> what's $x ?
[02:21] <sladen> Keybuk: defininate indefinate
[02:21] <sladen> Keybuk: "foobar"
[02:21] <Keybuk> whuh?
[02:21] <Keybuk> what has all this got to do with upstart?
[02:22] <gnomefreak> Keybuk: who is a good person to ping about FF in edgy?
[02:22] <Keybuk> gnomefreak: iwj
[02:22] <sladen> Keybuk: 'start' and 'stop' are major pieces of namespace, check?
[02:22] <tseng> gnomefreak: iwj
[02:22] <gnomefreak> figured as much ty guys
[02:22] <Keybuk> sladen: right, no package has ever dared use them as binary names
[02:22] <Keybuk> I think init has the right to :p
[02:23] <sladen> Keybuk: 'reload' and 'restart' are also names that make sense, check?
[02:23] <Keybuk> no
[02:23] <Keybuk> neither of those are in the upstart job life cycle
[02:23] <Keybuk> start and stop are very special
[02:23] <sladen> Keybuk: s/job life cycle/default state machine/
[02:24] <Keybuk> s/default//
[02:24] <sladen> Keybuk: 'start' and 'stop' are signals to the state machine
[02:24] <Keybuk> right, start and stop are the only two external changes permitted
[02:25] <Keybuk> reload, restart, kickupthebum, etc. don't need to be represented in the state machine, because they don't form part of the life cycle -- they're just separate actions (and we're off the spec here, as I deliberately omitted them from it <g>)
[02:27] <sladen> Keybuk: what's your proposed suggestion (whether it's in the spec or not) for sending arbitrary signals?
[02:28] <sladen> oooh, 'signal' is not taken either
[02:28] <Keybuk> for reload to make sense in the state machine, it would mean that it would have to be a goal
[02:28] <Keybuk> so you'd have "start", "stop" and "reload"
[02:28] <sladen> maybe 'kill' should correctly be called 'signal'
[02:29] <Keybuk> the reload goal change would need to kill the running process to force a state change, and move the job into the reloading state, which would then be able to have a "reload script" that did some magic to ... oh, oops, we killed the process
[02:29] <Keybuk> so it doesn't really make sense for them to be considered first class properties of a job
[02:29] <Keybuk> if you take a gui, there would be pretty toolbar buttons for start and stop
[02:30] <Keybuk> but things like "graceful restart" would be on a right-click menu for that job only
[02:30] <sladen> Keybuk: 'reload' is an arbitary signal (eg. apache may implement it with   kill -HUP `cat $pidfile` )
[02:30] <Keybuk> and then you get into messy things like having to be able to ask init for a list of actions on the job, provide translatable descriptions for them, etc.
[02:31] <sladen> Keybuk: 'restart' is a goal in the state machine (I think).  or is it   send(apache,stop), spin(apache,stop), send(apache,start)
[02:31] <Keybuk> restart doesn't need to be a goal
[02:32] <sladen> Keybuk: eg. the latter
[02:32] <Keybuk> just kill the process, but don't change the goal
[02:32] <Keybuk> if it's a daemon, it'll go through respawning
[02:32] <Keybuk> if it's a task, it'll go stopping/starting
[02:32] <sladen> Keybuk: I think that if it /can/ be implemented as a layer on top, then it shouldn't be in the core spec (which is a faily good API design rule)
[02:32] <Keybuk> (which you probably don't want)
[02:32] <Keybuk> yeah
[02:32] <Keybuk> another way of looking at is that you could have /etc/event.d/reload-apache
[02:32] <Keybuk> which has
[02:32] <Keybuk> on reload-apache
[02:33] <Keybuk> script
[02:33] <Keybuk>     kill -HUP $(pidof --job apache)
[02:33] <Keybuk> end script
[02:33] <Keybuk> -- 
[02:33] <sladen> Keybuk: I think for sanity, it should be  /etc/upstart.d/apache.reload
[02:34] <Keybuk> we settled on event.d :)
[02:34] <Keybuk> I'm vaguely avoiding using the word upstart anywhere except in the tarball name
[02:34] <Keybuk> the daemon is "init"
[02:34] <sladen> Keybuk: it would be nice if the signals for a particular task sorted alphabetically next to each other
[02:34] <Keybuk> I'm pretty happy that we can implement signals/actions/etc. on top of the current model
[02:34] <Keybuk> like I was able to implement dependencies
[02:34] <sladen> Keybuk: apache, apache.start, apache.stop, apache.reload
[02:35] <Keybuk> which, to me, suggests the model is simple and flexible enough
[02:35] <sladen> Keybuk: yup
[02:35] <Keybuk> though I'm not yet happy with the event naming/value
[02:35] <Keybuk> the main unhappy is that I want
[02:35] <Keybuk> "on apache" to mean "the apache job is running" but "on checkroot" to mean "the checkroot job is stopping" ("has finished")
[02:36] <Keybuk> and at the moment, there's no "null" values
[02:36] <Keybuk> so you can't do "while default-route is down"
[02:36] <Keybuk> because it's not down until it's been up at least once :p
[02:37] <Keybuk> and then there's "on default-route" ... does that mean when it's up, or when it changes, etc.?
[02:39] <Keybuk> I suspect the world would have been simpler if I just started off with "string only" events
[02:39] <Keybuk> but then I'd've still wanted to generate them for jobs
[02:39] <sladen> Keybuk: I just went to the toilet and I was thinking of  http://en.wikipedia.org/wiki/Subject_Verb_Object
[02:40] <Keybuk> hmm?
[02:43] <sbalneav> Keybuk: saw the upstart stuff, very nice.  Will be a HUGE help with diskless, where large chunks of your devices aren't there.
[02:44] <lgespee> Keybuk, upstart really looks nice, will it be stable enough to go into Main before Edgy? Or isn't that clear at all at the moment?
[02:44] <Keybuk> lgespee: I don't see why not; it seems very stable
[02:44] <lifeless> plus, its edgy.
[02:44] <lifeless> if its not bleeding, its not ready for edgy
[02:44] <bddebian> heh
[02:45] <zul> edgy makes me want to gouge out my eyes its so bleeding
[02:45] <lgespee> Keybuk: wow, really great, looks very promising
[02:45] <zul> or something like that
[02:45] <lgespee> zul, it's like living on the edge ;)
[02:45] <sladen> Keybuk: SVO -> Subject, Verb, Object.   Lingustics, Sentence construction.  It may help with both the command line tools and the config file format
[02:46] <lgespee> Keybuk, as a Ubuntu-NL teammember I heard soem rumours from teh Ubuntu-NL leader, but didn't actually believe it :D
[02:46] <lgespee> well great to know, I won't bother you all any further, keep up the great work, bye
[02:47] <sladen> Keybuk: if you are converting "on apache" -> "the apache job is running" -> "apache is running"
[02:48] <Keybuk> I'm starting to wonder whether we shouldn't split the events
[02:48] <Keybuk> so reserve "on" for system events, "at" for time events, etc.
[02:48] <Keybuk> but that bloats the config
[02:49] <sladen> Keybuk: if the format needs explanation then perhaps it's wrong :)
[02:50] <Keybuk> right
[02:50] <Keybuk> right now, I need to explain how it works, so it's wrong
[02:50] <Keybuk> and I really don't like that people can do "initctl trigger shutdown"
[02:50] <Keybuk> because that doesn't do the right thing
[02:50] <mjg59> Keybuk: So can we tie upstart in with gcc?
[02:50] <Keybuk> mjg59: umm?
[02:50] <mjg59> So your system gets rebuilt on every boot?
[02:50] <Keybuk> heh
[02:51] <bddebian> w00t
[02:53] <sladen> that would get the gentoo guys on board
[02:53] <Keybuk> start script
[02:53] <Lathiat> sure fire way of getting the gentoo guys to use it ;)
[02:53] <Lathiat> haha
[02:53] <Keybuk>   cd /src
[02:53] <Keybuk>   make
[02:53] <Keybuk> end script
[02:53] <Keybuk> exec /sbin/binary
[02:53] <Lathiat> -Olatest_hardware_from_this_boot
[02:54] <sladen> Keybuk: start shell script    start python script?
[02:54] <Keybuk> sladen: shell
[02:54] <sladen> Keybuk: why not make it really easy, take it out of the config file and do the dpkg thing of  have  thing.start
[02:55] <Keybuk> sladen: what happens when you need to have multiple thing.start ?
[02:55] <Keybuk> people would confuse thing.start with "run this when thing starts"
[02:55] <Keybuk> so you'd have someone not thing shipping thing.start
[02:55] <sladen> Keybuk: "would confuse" ?
[02:56] <Keybuk> right
[02:56] <Keybuk> so right now, it's obvious that the "start script" bit in /etc/event.d/udev is something for the udev author to use
[02:56] <sladen> action start, action stop
[02:56] <Keybuk> if it were a separate file, e.g. /etc/event.d/udev.start you could end up with some other package trying to ship a udev.start script so that it's run before udev starts
[02:56] <Keybuk> when it should be a separate job entirely that happens to be run when udev is starting
[02:57] <sladen> Keybuk: in which case that would break the policy
[02:58] <sladen> Keybuk: technical solutions to policy issues and policy solutions to technical issues generally don't work
[02:59] <Keybuk> true but policy issues are often caused by bad technical solutions
[02:59] <sladen> Keybuk: the only thing that would 'prevent' another package shipping their own '/etc/event.d/udev' would be dpkg complaining that the same file is owned by two packages
[02:59] <Keybuk> I'm reasonably sure that upstart needs to be very simple
[02:59] <Keybuk> and not allow arbitrary expansion in any number of directions
[02:59] <Keybuk> but instead just allow lots of building blocks
[03:00] <Keybuk> the more complex levels of interactions one tries to layer on top, the more of a headache one gets figuring out where the deadlocks can lie
[03:00] <sladen> start == pre-start, stop == post-start, kill == pre-stop ?
[03:00] <Keybuk> err?
[03:00] <Keybuk> start = pre-running, stop = post-running
[03:00] <Keybuk> there is no kill
[03:01] <Keybuk> could rename them pre and post ;)
[03:01] <sladen> Keybuk: (thinking of dpkg-style naming of start/stop scripts), there is {pre,post}{inst,rm}.  check?
[03:02] <sladen> renaming does seem like it might be more accurate
[03:02] <Keybuk> I'm thinking that the dpkg-style scripts are not a good design to follow
[03:02] <Keybuk> given everyone has to read the manual every time they try and use them
[03:02] <sladen> and people are might be less like to try to run  'pre-start' directly, and especially unlikely to run 'post-start' directly :)
[03:03] <sladen> s/like/likely/
[03:03] <Keybuk> you can't run them directly ;)
[03:03] <Keybuk> they're in the config file
[03:04] <sladen> having them separate would make 'script' and 'exec' redundant
[03:04] <Keybuk> no it wouldn't
[03:05] <Keybuk> you can exec /path/to/script already if you want
[03:05] <sladen> Keybuk: anything that can be done inside  script ... endscript  or  exec "path/filename"  could be done with just having  "path/filename"  exist
[03:05] <Keybuk> then how do you specify path/filename ?
[03:07] <sladen>  $base = "/etc/event.d/"; $who = "apache";  $action = "pre-start";  $filename = strcat($base,$who,$action);
[03:07] <Keybuk> that only replaces "start script" ... it doesn't replace "script" or "exec"
[03:07] <Keybuk> how do you specify the name of the daemon binary to run
[03:08] <sladen> Keybuk: man 2 symlink
[03:08] <Keybuk> err, I really don't think we should be symlinking daemons into /etc
[03:08] <Keybuk> that's a bad idea
[03:09] <sladen> Keybuk: why is that different to specifying the name of an executable in a configuration file, in etc?
[03:10] <Keybuk> one can be modified trivially in a text editor
[03:10] <Keybuk> one requires heavy filesystem lifting
[03:10] <Keybuk> "one file per config option" sounds a bit djbish
[03:10] <Robot101> says the qmail advocate :)
[03:11] <sladen> Keybuk: why duplicate existing functionality?
[03:11] <Keybuk> sladen: what existing functionality?
[03:11] <sladen> Keybuk: databases and filesystems
[03:11] <Keybuk> Robot101: I use qmail because I know it
[03:12] <Keybuk> I know how it delivers mail, how it works, how to fix it, etc.
[03:12] <Keybuk> and I have no pressing desire or need to learn anything else
[03:12] <Keybuk> sladen: eh?
[03:12] <Keybuk> how have you strayed here?
[03:13] <Robot101> Keybuk: I was just pulling your leg; I use postfix for the same reasons. I'll shut up now. :)
[03:14] <Keybuk> I really don't see how "always execs an executable at a fixed path on the filesystem, which means you must place one there or arrange a symlink to the right place" is better than "a line in the config file says what to exec, and provides arguments"
[03:14] <Keybuk> e.g. right now you can "exec /sbin/udev --daemon"
[03:14] <Keybuk> to do that with your proposal, I'd have to write an /etc/event.d/udev.exec script that had in it
[03:15] <Keybuk> #!/bin/sh -e
[03:15] <Keybuk> exec /sbin/udev --daemon
[03:15] <sladen> Keybuk: if a symlink would do the job in a transparent fashion (in the less common case) and a shell script would do the job (in the more common case)---both of which are already core kernel functionality;  which duplicate (obfuscate) those with 'exec' and 'script...endscript' options in a configuration file?
[03:16] <sladen> s/which/why/
[03:20] <sladen> Keybuk: I'm now coming around to the idea of   to "pre-start" exec "/usr/bin/apache" "--daemon" "xyzzy"   (or similar) in the config file
[03:22] <sladen> Keybuk: maybe I'm just untouched by the 'script' business and the idea of having two (very similar) methods in the config file, both of which can do each other
[03:22] <Keybuk> the difference between exec and script is pretty obvious
[03:23] <Keybuk> exec runs sh -c exec ...
[03:23] <sladen> oh. OH
[03:23] <Keybuk> script runs sh /dev/fd/%d and puts the lines up to end script in that
[03:24] <sladen> Keybuk: I had assumed 'exec' called 'execve()'
[03:24] <sladen> Keybuk: if you're still calling through the shell even for an exec then there isn't even a speed difference in its favour
[03:24] <Keybuk> it calls exec() directly if there's no interesting characters in the string
[03:25] <Keybuk> so "exec /sbin/udev --daemon" would just do exec({ "/sbin/udev", "--daemon" }), yes
[03:25] <sladen> Keybuk: and native exec() would be better as it functions even in the light of no shell
[03:25] <sladen> Keybuk: two codepaths for one command?
[03:25] <Keybuk> whereas exec /sbin/udev $FOO would call exec({ "/bin/sh", "-c", "/sbin/udev $FOO" })
[03:25] <Keybuk> *shrug*
[03:26] <Keybuk> it seemed to be a copy semantic
[03:26] <sladen> Keybuk: just use 'script...endscript' for the secondone!
[03:26] <Keybuk> (sysvinit, cron and atd all do the same thing)
[03:26] <Keybuk> the config file offers lots of short cuts
[03:26] <Keybuk> mostly because I'm lazy and like to put them in :p
[03:26] <Keybuk> e.g. "while FOO is BAR" is identical to "start when FOO is bar\nstop on FOO"
[03:27] <shackan_> FOO and BAR being event identifiers ?
[03:27] <Keybuk> FOO being an event name, BAR being an event value
[03:28] <sladen> Keybuk: "while FOO is BAR";  do what?
[03:28] <shackan_> real world example for doc-reading impaired ? :)
[03:28] <Keybuk> ok
[03:28] <Keybuk> so events have values
[03:28] <Keybuk> when you change the value of an event, the event is triggered with that value
[03:28] <Keybuk> the event is also triggered with no value
[03:29] <sladen> while FOO.state == 'stopped'
[03:29] <sladen> while FOO.state == 'stopped' do yeild
[03:29] <Keybuk> so if I set FOO to BAR, any jobs which have "on FOO" and "when FOO is BAR" will be started
[03:29] <Keybuk> uhh, pseudocode won't help me understand it?
[03:30] <sladen> Keybuk: but it helps *me* understand it
[03:30] <Keybuk> eh
[03:30] <Keybuk> FOO doesn't have state
[03:30] <Keybuk> it's an event, not a job
[03:31] <sladen> Keybuk: then that's an edge, not a level and you should be using 'if' not 'while'
[03:31] <Keybuk> "startup" is an event, "default-route is up" is an event
[03:31] <Keybuk> on startup
[03:31] <sladen> Keybuk: an event does not exist for a length of time, it happens in an instant
[03:31] <Keybuk> when default-route is up
[03:31] <Keybuk> would be those two equivalents
[03:31] <Keybuk> it happens that "while EVENT is VALUE" means your job is started WHEN EVENT is VALUE and stopped ON EVENT (ie whenever it changes to something else)
[03:31] <Keybuk> this has already noted to be confusing
[03:32] <sladen> Keybuk: a state does exist for a length of time, it is something that is achieved, or reached
[03:32] <Keybuk> which was the beginning of this conversation
[03:32] <shackan_> but the *event name* "default-route is up" does have some *state* information (that is, that the route is up :)
[03:32] <Keybuk> right
[03:32] <Keybuk> but "startup" doesn't
[03:32] <Keybuk> and then there's tricky ones
[03:33] <sladen> the event in this case is   default-route.up
[03:33] <Keybuk> is "writable-filesystems" a one-shot event
[03:33] <Keybuk> or should there be a filesystems are writable state ?
[03:33] <sladen> so you can simply have   on default-route.up
[03:33] <Keybuk> stop inventing syntax :p
[03:33] <Keybuk> ok ...
[03:33] <Keybuk> so what happens if one does "on default-route" instead ?
[03:34] <sladen> preferably  on default-route.up do something
[03:34] <sladen> on default-route.up do start
[03:34] <Keybuk> the "do something" is always either "set the goal to start" or "set the goal to stop"
[03:34] <sladen> on default-route.down do stop
[03:34] <Keybuk> ok ...
[03:34] <Keybuk> now reverse that
[03:34] <Keybuk> on default-route.down do start
[03:34] <Keybuk> on default-route.up do stop
[03:35] <Keybuk> when will that get started?
[03:35] <sladen> the goal called 'start' will be set when an event goes past called 'default-route.down'
[03:35] <shackan_> so people should call their events like 'mysql-running', 'mysql-updating' etc..,      or just use 'mysql' for the event name and then read its state ?
[03:35] <Keybuk> right, so it won't get started until the network has come up and gone back down again
[03:36] <Keybuk> you'd need on startup do start
[03:36] <Keybuk> which may not be a bad thing, as it makes the world more clear
[03:36] <Keybuk> you could then have
[03:36] <Keybuk> on mysql.starting do start
[03:36] <Keybuk> on mysql.running do start
[03:37] <sladen> Keybuk: so that is an event, that that is what is currently broken in sysvinit (and worked around by having K??* scripts)
[03:37] <Keybuk> the latter could be just "on mysql", which is a different event, but triggered at the same time as running (for services) or stopping (for tasks)
[03:37] <shackan_> so the syntax is <event name>.<event state> ?
[03:37] <grexk> I always fail to compile xen-source from edgy to dapper. http://pastebin.com/778461?
[03:37] <Keybuk> shackan_: event state is confusing, apparently
[03:38] <sladen> Keybuk: on mysql.isrunning() == true: do ...
[03:38] <sladen> Keybuk: (ignore the fact that it is puesudo code)
[03:39] <sladen> Keybuk: bah, state/event; level/edge;  bah
[03:39] <Keybuk> ?
[03:39] <sladen> Keybuk: yes, "event state is confusing, apparently"
[03:39] <sladen> events *happen* on the transition of states
[03:39] <Keybuk> job events feel like they want to have state
[03:40] <shackan_> "feel like they want to" ? omg :D
[03:40] <sladen> Keybuk: what is a "job event"
[03:40] <Keybuk> sladen: the events that occur every time a job changes state
[03:40] <Keybuk> maybe that's what I confused
[03:40] <shackan_> let's hope upstart will never feel like willing to format my disks
[03:41] <Keybuk> the events should be single-fire things, the state should be in the job machine
[03:41] <shackan_> I totally second the 'events happen on the transition of states'
[03:41] <Keybuk> the mysql *job* has state, and fires events when the state changes, which get forgotten once they're processed
[03:41] <sladen> shackan_: upstart's job is to get /other/ things to format your disks on its behalf :)
[03:42] <Keybuk> on idle
[03:42] <Keybuk> mke2fs /dev/root
[03:42] <shackan_> sladen, I tought its job was to take over the world? :)
[03:43] <sladen> shackan_: no, that's ubuntu's job.  upstart is merely a means to an end
[03:43] <Keybuk> sladen: yeah, I really think events shouldn't have values and grab
[03:43] <sladen> Keybuk: seems that, for things to have state, they must have a way of querying if that state is true
[03:43] <Keybuk> crap
[03:43] <Keybuk> they should just be arbitrary strings
[03:43] <Keybuk> which may follow a naming pattern
[03:43] <sladen> yes
[03:43] <sladen> yes
[03:45] <sladen> on each transition, the previous state is left and the next on is entered
[03:45] <sladen> stopped -> started
[03:45] <shackan_> o rly? (errrrr, sorry)
[03:45] <sladen> stop.left, start.entered.  state == started
[03:46] <Keybuk> stopping -> starting  </pedant> :p
[03:46] <shackan_> sladen, your pseudocode does actually confuse :p
[03:46] <sladen> maybe we should  s/ing$//;s/ed$//g
[03:46] <Keybuk> sladen: that would be incorrect for the state machine
[03:46] <Keybuk> the job state has to be an "ing" because it is a present perfect(?)
[03:47] <Keybuk> ie. it's what the job is actually doing right now
[03:47] <Keybuk> the events could have different names, of course
[03:47] <sladen> shackan_: perhaps you could provide psuedocode that does /not/ confuse.  I sometimes find your random comments confusing.
[03:47] <Keybuk> waiting -> starting
[03:47] <Keybuk> starting -> running
[03:47] <Keybuk> running-> stopping
[03:47] <Keybuk> stopping -> waiting
[03:47] <Keybuk> are the primary transitions
[03:48] <sladen> post-stop, pre-start, post-start, pre-stop
[03:49] <sladen> yup
[03:51] <shackan_> event are fired during transitions or when states are reached ?
[03:51] <shackan_> +s
[03:52] <Keybuk> during transitions
[03:52] <Keybuk> waiting => "nothing is happening"
[03:52] <Keybuk> starting => "the job's start script (if any) is running"
[03:52] <Keybuk> running => "the job's primary process is running"
[03:52] <Keybuk> stopping => "the job's stop script (if any) is running"
[03:53] <shackan_> so, if we go A -> B, when the 'on B' trigger will be fired, the current state will still be A ?
[03:54] <Keybuk> no, the state will be B, obviously, you went from A -> B :p
[03:54] <shackan_> but you fired the event during the transition, before the state switched to B :)
[03:55] <Keybuk> isn't the definition of a transition that the state is switching?
[03:56] <Keybuk> does it need to?
[03:56] <lifeless> eww. polling.
[03:56] <Keybuk> shackan_: upstart's states are gated
[03:57] <shackan_> ouch, maybe 'transition from A to B' should be a 'transition state' itself? (let's call it C)
[03:57] <shackan_> ok, </crack>
[03:57] <Keybuk> you can only move from starting to running if the start script has terminated
[03:57] <lifeless> btw, this is very similar to the mswindows service management api in terms of the state stuff
[03:57] <sladen> and, on boot, fired off 'is_stopped' events for each of the daemons it knows about 
[03:57] <Keybuk> which, given the thing that moves the state is the child reaper for the start script, is not surprising :p
[03:57] <Keybuk> lifeless: *hides the book under his desk*
[03:58] <sladen> Keybuk: so, how do you moved from  waiting->starting  if the previous transition was not achieved
[03:58] <lifeless> Keybuk: :)
[03:58] <Keybuk> sladen: you can't be in waiting if the previous transition wasn't achieved?
[03:58] <Keybuk> you'd still be in stopping
[03:58] <Keybuk> lifeless: it's similar to the design of any sensible service management api
[04:01] <Keybuk> by gating the states, we don't need messy interim states
[04:02] <sladen> cron has  @reboot
[04:02] <sladen> I like that syntax
[04:02] <Keybuk> at reboot
[04:02] <Keybuk> though upstart uses reboot to mean "after jobs have been stopped, and you want to reboot the machine" :p
[04:02] <Keybuk> ie. run rc6 currently
[04:03] <sladen> so @reboot is actually  at boot
[04:03] <Keybuk> right
[04:04] <sladen> @start /usr/bin/asdf
[04:04] <sladen> @stop kill `pidof asdf`
[04:05] <Keybuk> that's what current init does
[04:05] <Keybuk> and not what upstart does
[04:05] <sladen> @bedtime irssi /away night night
[04:06] <sladen> Keybuk: I'll think on it over night.  Something about the non-heriarchy, multiline config-file without qualifiers is getting my brain
[04:07] <sladen> Keybuk: you don't need endscript, there is the    \   syntax at the end of the line
[04:07] <sladen> Keybuk: or the  <<<EOF  syntax
[04:08] <sladen> both of which cope with escaping
[08:41] <Kamion> sladen: macosx open> isn't that see(1)?
[08:42] <Burgundavia> sladen: I need UWN 11 on the fridge, stat ;)
[08:42] <jdub> Kamion: pretty much, but using all of osx's happy mime foo (gnome-open would be a more appropriate analogue)
[08:45] <Kamion> oh, I always forget that the desktops reinvented the existing mime handling
[08:45] <Kamion> I tend to ignore them :)
[08:47] <grexk> Anyone want to check this out http://pastebin.com/778609
[08:48] <jdub> Kamion: i hammered pretty hard to have mailcap compat (or direct use) in gnome - didn't happen.
[08:48] <Kamion> grexk: it's polite to tell people what it is rather than expecting them to follow the URL to find out
[08:48] <grexk> sorry
[08:50] <dholbach> good morning
[08:51] <Kagou> hi
[08:52] <grexk> I can't perfectly compile xen-source-2.6.16 lately, checking launchpad seems it works well with i386?
[08:54] <grexk> or should I just use deb binary from edgy to dapper.
[09:02] <HiddenWolf> grexk: edgy uses a newer libc, it's not a good idea to replace that lib. :)
[09:02] <HiddenWolf> grexk: what you can do is get the source, build-deps and build it yourself on dapper.
[09:04] <grexk> Been doing that but I can't compile it perfectly with make-kpkg:(
[09:05] <HiddenWolf> I'm no expert, but I've managed both rhythmbox and gossip with dpkg-buildpackage
[09:05] <grexk> no success either:(
[09:06] <HiddenWolf> grexk: perhaps you can find help in #ubuntu-kernel? 
[09:06] <grexk> thanks
[09:31] <sivang> morning all
[09:32] <Hobbsee> hey sivang 
[09:32] <grexk> morning
[09:32] <sivang> hey Hobbsee , how are things?
[09:33] <Hobbsee> sivang: okay.  i keep sleeping thru uni classes, which is kinda bad though.
[09:33] <zyga> hello everyone
[09:34] <sivang> Hobbsee: don't. Uni is important , trust me
[09:34] <Hobbsee> sivang: yes, exactly.  
[09:35] <sivang> Hobbsee: yes, I recall that from my pre-uni studies. It's like missing a day is roughly as loosing the introduction and the fin abut how for instnace, electromagnetism works...
[09:37] <Hobbsee> sivang: yeah, true
[09:40] <sivang> Hobbsee: and trust me, when you can't present too many credentials for something you want to do, at least having completed a university degree can be considered as one big and demanding project you've done successfuly ;-)
[09:41] <Hobbsee> sivang: true that.  i dont usually have this problem - just the last couple of weeks.
[09:46] <sivang> TheMuso: known :-)
[09:54] <dholbach> keybuk, Kamion: could one of you please liberate libtelepathy from binary new (soname change)?
[09:55] <\sh> moins
[09:58] <rouzic_ausente> alegrate, /me ha vuelto
[10:23] <seb128> doko: is your mail against closing old "Needs Info" bugs too?
[10:26] <doko> seb128: maybe, but I agree with Dennis' reply
[10:27] <seb128> doko: ok, because usually people close old Needs Info without a reply for some timez
[10:27] <Hobbsee> doko: in kde-based bugs, often that doesnt make sense - because kde upstream fixes a lot more with each version than they tend to put in their changelogs
[10:27] <Hobbsee> they put the major bugfixes in, but they dont put in every little single change, usually
[10:27] <Hobbsee> although people should try to reproduce before closing
[10:28] <doko> marketing what, bugs? ;-P
[10:28] <seb128> Hobbsee: so you close random bugs because they might be fixed by a new version?
[10:28] <Hobbsee> seb128: no, of course not
[10:28] <seb128> Hobbsee: usually the way it works it that you verify that the bug is fixed before closing
[10:29] <Hobbsee> doko: i'm not sure, i'm trying to ignore it :P
[10:29] <Hobbsee> seb128: true that
[10:29] <seb128> Hobbsee: and KDE people doing a poor job documenting what they do doesn't change that :p
[10:29] <Hobbsee> sorry - the thought was there, the execution was shocking.
[10:29] <Hobbsee> seb128: hehe, true that
[10:50] <pygi> sivang, poke?
[10:55] <joumetal> linux-libertine package (font) is in Debian testing. It seems to work with dapper without any changes. Could it be added to edgy?
[10:55] <Riddell> Hobbsee: KDE changelogs are very detailed, and include full SVN logs for maximum details
[10:55] <Hobbsee> Riddell: hmmm okay.  i was thinking of a lot of the universe packages, etc
[10:56] <sivang> pygi: hi
[11:00] <HiddenWolf> Hobbsee: we all want a part of you. ;)
[11:00] <Hobbsee> ....
[11:00] <Kamion> dholbach: done
[11:00] <dholbach> Kamion: thanks muchly.
[11:02] <Hobbsee> HiddenWolf: did someone steal your brain too?
[11:02] <HiddenWolf> Hobbsee: I never had any. :)
[11:02] <Hobbsee> ah
[11:13] <Mithrandir> ogra: how's it going wrt getting your CDs down to a reasonable size?
[11:57] <ogra> Mithrandir, just merging seeds ... lets see
[12:05] <zyga> hi, is install-info a known issue?
[12:05] <ogra> mjg59, ping
[12:15] <ogra> one g-p-m patch less :D
[12:15] <dholbach> yeah :)
[12:18] <zyga> guys what's wrong with install-info?
[12:18] <sivang> anybody has an idea why google has vanished from our firefox's search bar?
[12:18] <sivang> (and for some reason can not be add
[12:18] <sivang> ed)
[12:25] <mjg59> ogra: Hi
[12:26] <ogra> mjg59, i have a weird behavior of usplash on thin clients
[12:26] <ogra> the keyboard in the login manager doesnt work unless i switch to tty1 and back
[12:26] <ogra> well, it kinda works after a loong delay and only prints '''' chars  
[12:27] <ogra> if i switch off usplash for the boot all is fine ... 
[12:28] <StevenK> mjg59: I have the same problems with Debian that you do, if that's news.
[12:29] <mjg59> ogra: Erm.
[12:30] <mjg59> I can't think of any reason why it should behave differently for thin clients
[12:30] <ogra> it changed with my recent update ... (i havent updated for 3 weeks before)
[12:30] <ogra> because we dont use GDM =
[12:30] <ogra> ?
[12:30] <mjg59> Well, there's been a lot of code changes
[12:30] <mjg59> What do you use?
[12:30] <ogra> and i kill it in the wrong place in ldm or miss something that needs to be added ? :)=
[12:31] <mjg59> You shouldn't kill it
[12:31] <mjg59> The VT switch will let it clean up
[12:32] <ogra> so
[12:32] <ogra> if pidof usplash > /dev/null; then
[12:32] <ogra>                         /etc/init.d/usplash stop
[12:32] <ogra>                 fi
[12:32] <ogra> is not appropriate anymore ? 
[12:32] <ogra> (got that at the top of the initscrit, before i start the X session)
[12:33] <mjg59> Uhm
[12:33] <ogra> i had to add it because usplash dropped my to tty1 else
[12:33] <mjg59> /etc/init.d/usplash stop will not do what you think it does
[12:34] <mjg59> Look at how gdm does it
[12:34] <ogra> i think thats what it did for dapper
[12:34] <ogra> i didnt look in edgy yet
[12:34] <infinity> ogra: You probably want "start", not "stop", which is what gdm uses.  Yes, confusion, I know.
[12:34] <ogra> hehe
[12:35] <infinity> usplash's init script is the silliest thing I've ever accidentally contributed to.
[12:35] <infinity> But I blame mvo, just 'cause I can.
[12:35] <ogra> how about rewriting it at some point to be sane :)
[12:35] <infinity> Yeah, yeah. :)
[12:36] <infinity> Or obsoleting it entirely somehow.
[12:36] <ogra> upstart might help here :)
[12:36] <thom> can't you blame scott? i'm sure it must be his fault
[12:37] <infinity> thom: Scott didn't really touch usplash until edgy, so the brain-damage in breezy and dapper is something I get to share responsibility for with mjg59 and mvo, mostly.
[12:37] <infinity> thom: I'll happily blame him from here on in, though!
[12:44] <ogra> mvo calling "start" to stop usplash :)
[12:44] <zyga> guys does anyone know what's install-info mess is all about?
[12:44] <mvo> ogra: that is called "newspeak" ;)
[12:45] <ogra> lol
[12:45] <ogra> :)
[12:45] <Hobbsee> ogra: it doesnt work :P
[12:46] <ogra> Hobbsee, well, was worth a try :)
[12:46] <Hobbsee> heh
[12:46] <ogra> mjg59, thanks, the keyboard works as expected now :)
[12:48] <jono> he
[12:48] <Treenaks> eh?
[12:48] <Hobbsee> hey jono 
[02:26] <Gloubiboulga> Kamion, hi, is it possible to run a new xubuntu isos build?
[02:30] <Mithrandir> Gloubiboulga: just new ISOs or new livefs too?
[02:31] <Gloubiboulga> Mithrandir, new livefs is needed too I think
[02:31] <tepsipakki> netboot-installer has old components, so d-i should be rebuilt
[02:32] <Mithrandir> Gloubiboulga: xubuntu livefs running now
[02:32] <Gloubiboulga> Mithrandir, thanks
[02:35] <Kamion> tepsipakki: yes, I'm going to do that after all my no-more-devfs stuff is through
[02:35] <tepsipakki> kamion: ok, thanks
[02:35] <Kamion> plus the kbd-chooser change I'm working on now
[02:35] <Kamion> I didn't get a chance to do it at the sprint last week
[02:36] <tepsipakki> devfs is going to go? does that affect the disk-device-id that the d-i uses?
[02:36] <Mithrandir> tepsipakki: we haven't used devfs as such for ages.
[02:36] <Kamion> devfs disappeared long ago - the change is to get rid of devfs *paths*
[02:36] <Kamion> so yes, d-i will start using /dev/hda1 instead of /dev/discs/disc0/part1, etc.
[02:37] <Kamion> it already sort of does, but only patchily
[02:37] <tepsipakki> right, good to know
[03:05] <Mithrandir> ogra: well, getting anywhere?
[03:05] <ogra> Mithrandir, yes, to lunch ... i'll trigger a new iso afterwards ... :)
[03:06] <janimo> Gloubiboulga: hi
[03:06] <Mithrandir> ogra: so you've managed to shrink it a bit, then?
[03:06] <Gloubiboulga> hi janimo 
[03:06] <janimo> Gloubiboulga: I added pyxfce to desktop seed as well, it will need a MIR
[03:06] <Gloubiboulga> janimo, I'm not sure that it's a good idea
[03:06] <janimo> Gloubiboulga: made progress on xkb?
[03:07] <janimo> Gloubiboulga: why?
[03:07] <Gloubiboulga> pyxfce seems unmaintained
[03:07] <Gloubiboulga> I haven't seen an svn since months
[03:07] <janimo> Gloubiboulga: there's at least one plugin upstream which uses it upstream no?
[03:07] <Gloubiboulga> janimo, yes
[03:08] <Mithrandir> Gloubiboulga: ISOs building
[03:08] <Gloubiboulga> Mithrandir, thanks again :)
[03:10] <Mithrandir> Gloubiboulga: .. and built.
[03:11] <Gloubiboulga> lets see who much Mo we'll have to remove this time...
[03:15] <ogra> Mithrandir, lets see, i found out that tomboy was still in the seeds and the foomatic stuff should gain a bit as well 
[03:16] <rodarvus> heh, and I remember ogra quite happy just a few weeks ago, because we had gained ~20mb from python deps :)
[03:16] <ogra> rodarvus, :P
[03:17] <ogra> we'll get it in shape ... we'll just drop X, gnome and openoffice :P
[03:18] <Mithrandir> nobody uses OOo anyway.  LaTeX ftw. ;-P
[03:18] <Mithrandir> also, I'm using "ftw" far too much those days.
[03:19] <rodarvus> yay LaTeX!
[03:19] <sivang> I prefer genuine rubber..
[03:19] <rodarvus> I think two things will likely have to happen in the medium-to-near future: split language packs per country
[03:19] <rodarvus> and drop OOo helps from the cd :)
[03:20] <rodarvus> . o O ( who needs help files anyway ) :D
[03:21] <ogra> right, its even a lot more education you gain through LaTeX !
[03:21] <rodarvus> openoffice.org-help-en-us is on the livecd
[03:22] <rodarvus> ~11mb compressed, 22mb decompressed
[03:22] <HiddenWolf> rodarvus: everyone needs help with the beast that is Oo. :)
[03:22] <rodarvus> heh :)
[03:22] <rodarvus> it would help if the OOo help was actually useful
[03:22] <Gloubiboulga> Mithrandir, did you run the build for alternate isos too?
[03:22] <rodarvus> (but anyhow)
[03:23] <ogra> rodarvus, its totally useful (on 3GHz machines with 4Gig of ram at least) 
[03:23] <janimo> mvo hi, re the gtkhtml2 use in g-a-i. It looks like it is used to render 3rd party commercial EULAS only?
[03:24] <Mithrandir> Gloubiboulga: nope, you want those?
[03:24] <rodarvus> yes, this is another problem. given it uses gcj runtime to run, OOo help is dog slow, and uses an incredibly high amount of RAM
[03:24] <Gloubiboulga> Mithrandir, yes please :)
[03:24] <Mithrandir> Gloubiboulga: running
[03:24] <Gloubiboulga> thanks
[03:26] <ogra> edgy-install-i386.iso          29-Aug-2006 14:18  722M 
[03:26] <ogra> :((((((
[03:26] <ogra> where do i get 22 meg ...
[03:26] <rodarvus> ouch.
[03:26] <ogra> hrm ..
[03:26] <ogra> and its only i386
[03:27] <rodarvus> !!
[03:27] <ogra> the others are both at 716 only
[03:27] <ogra> i wonder where the 6 meg come from
[03:27] <rodarvus> I expected i386 to be smaller than amd64 at least
[03:27] <ogra> well, the seeds are tweaked already to compensate that 
[03:28] <ogra> (amd64 and ppc dont ahve all apps i386 has)
[03:28] <Nafallo> ogra: oo-help :-)
[03:28] <rodarvus> ogra, doko made a very good suggestion, btw
[03:29] <rodarvus> (on ubuntu-devel@)
[03:29] <ogra> funny ... http://cdimage.ubuntu.com/edubuntu/daily/20060829.1/report.html doesnt show and amd64 uninstallables
[03:29] <ogra> hmm
[03:29] <ogra> why not drop vim completely in edubuntu ...
[03:29] <ogra> i wonder who would complain
[03:30] <rodarvus> vim-tiny is tiny
[03:30] <ogra> (apart from myself)
[03:30] <rodarvus> but if you have at least nano, I think thats ok
[03:31] <rodarvus> FWIW, most other linux distributions install vim-tiny (or elvis) on their default installs
[03:32] <ogra> ok, seed changed
[03:32] <ogra> other suggestions ?
[03:34] <Kamion> ogra: er ... where did you make that change?
[03:34] <dholbach> ogra: what is ttf-dustin and xaos for?
[03:34] <ogra> dholbach, xaos is a fractal generator
[03:34] <ogra> the dustin font is required by kalzium iirc
[03:35] <ogra> Kamion, minimal in the edubuntu seed
[03:35] <Kamion> ogra: I'm sorry, but you can't do that
[03:35] <Kamion> ogra: it will have no effect
[03:35] <ogra> oops
[03:35] <Kamion> please revert that
[03:35] <ogra> ok
[03:35] <ogra> doing so
[03:35] <Kamion> the minimal and standard seeds in derivatives basically don't do anything
[03:35] <Kamion> so, I was also thinking of moving from vim to vim-tiny in Ubuntu minimal
[03:36] <ogra> that'd be great
[03:36] <Kamion> in some ways it would be better, because vim-tiny is configured to act like vi if you run it as vi, and like vim if you run it as vim
[03:36] <Kamion> (the compatible flag)
[03:36] <Kamion> I was thinking that it wouldn't help much because you'd also want vim on the CD - vim-tiny is missing too many features
[03:36] <_ion> Moving to vim-tiny is okay, but only having nano and no vi derivative would suck.
[03:37] <slomo> Kamion: hi :) did you already have time to look at my two dbus mails?
[03:37] <Kamion> but maybe you'd want to leave vim off the Edubuntu CD?
[03:37] <Kamion> _ion: no intention of dropping vi
[03:37] <Kamion> I'd hurt people if that happened
[03:37] <Kamion> slomo: oh, not yet, will do shortly
[03:37] <Mithrandir> Gloubiboulga: and done
[03:37] <ogra> Kamion, well, -minimal pulls it in currently ... there is no other occurence of vim in the edubuntu seeds
[03:38] <ogra> or do you mean completely ? 
[03:38] <slomo> Kamion: thanks :) btw, when will the main freeze for knot2 start?
[03:38] <Kamion> ogra: indeed, but I'd probably add it to Ubuntu ship - or maybe even desktop
[03:38] <ogra> ah
[03:38] <ogra> right
[03:38] <ogra> no, i wouldnt merge that
[03:38] <Kamion> vim-tiny is missing e.g. syntax highlighting
[03:38] <ogra> i think edubuntu could even go without vi 
[03:38] <seb128> do we need vim on desktop CD? I mean vim users are probably able to install it ...
[03:39] <Kamion> seb128: yeah, not sure about that, I think it should be on the CD though
[03:39] <Gloubiboulga> thanks Mithrandir 
[03:39] <zul> i would want vim on a desktop cd alot users use vim
[03:39] <Kamion> and a lot of vim users, while competent, won't necessarily be familiar with Debian/Ubuntu - they'll just start vi and notice that it sucks
[03:40] <Riddell> Kamion: could you build a kubuntu livefs
[03:40] <seb128> don't ship any vi at all then?
[03:40] <Kamion> ogra: I'm not going to drop vi altogether from minimal
[03:40] <Kamion> seb128: no
[03:40] <seb128> nano is enough
[03:40] <seb128> ok
[03:40] <Kamion> no it's not
[03:40] <ogra> seb128++
[03:40] <seb128> just my opinion, but I don't use vi
[03:40] <ogra> i use vi daily
[03:40] <azeem> it would be alright to have a big warning/notice on the first invocation of vi as vi that this is vim in compat mode
[03:40] <Treenaks> Kamion: whatever works, as long as 'vi' doesn't start nano... as I've seen on some BSD systems here.. *shudder*
[03:40] <azeem> maybe
[03:40] <Kamion> we drop vi over my dead body :)
[03:40] <ogra> but i dont have a prob to install it 
[03:40] <Kamion> it belongs in a base Unix system
[03:40] <seb128> Kamion: we are lucky that you are not an emacs user then :p
[03:41] <_ion> treenaks: Augh!
[03:41] <ogra> haha
[03:41] <Kamion> seb128: yes, we are :)
[03:41] <doko> Kamion++, seb128----
[03:41] <Treenaks> _ion: my words exactly
[03:41] <Kamion> Riddell: sure, building
[03:41] <Kamion> anyway, vim-tiny is half a megabyte
[03:41] <Kamion> I think it's well worth it just for not pissing off server admins
[03:42] <Kamion> vim I acknowledge as more debatable
[03:42] <Kamion> the big chunk of space is vim-runtime - unfortunately that's also the bit that's really nice to have
[03:43] <azeem> put vim-tiny into -minimal, and vim into -server?
[03:43] <LarstiQ> didn't this get resolved in Debian?
[03:43] <Kamion> LarstiQ: it is not possible for Ubuntu task choices to get resolved in Debian, so no
[03:43] <LarstiQ> Kamion: right, task choices.
[03:43] <azeem> and try to get desktop users to notice they should install vim for the real deal
[03:44] <LarstiQ> Kamion: but the discussion was much the same
[03:44] <Kamion> yes, that's why vim-tiny was created
[03:44] <Kamion> but that doesn't necessarily help with the question of whether providing vim on the CD is a good idea
[03:44] <infinity> Kamion: The full vim does seem excessive for -minimal
[03:45] <bddebian> Good morning
[03:45] <Kamion> hmm, I wonder whether /usr/share/vim/vim70/lang can be stripped and put into langpacks
[03:45] <LarstiQ> Kamion: good luck with that :)
[03:48] <ogra> seb128, what will break if i drop gnome2-user-guide from edubuntu ? are there any hardcoded referecnes to it anywhere ?
[03:49] <seb128> ogra: the help from a bunch of gnome apps
[03:49] <ogra> hrm ...
[03:49] <seb128> ogra: I think some capplets, etc point to documens from the user-guide
[03:49] <seb128> ogra: so you will get a yelp complaining about some reference not found
[03:49] <ogra> ok, so i have to keep that
[03:49] <dholbach> drop blender and xaos
[03:50] <seb128> why do we have blender to main?
[03:50] <ogra> dholbach, i cant drop xaos (and its only 500k or so)
[03:50] <bddebian> For Margaritas?
[03:50] <ogra> seb128, its in edubutu-desktop
[03:50] <seb128> ogra: ah, k
[03:51] <seb128> ogra: I was wondering yesterday because some user asked me if we had planned to update to the current Debian version for edgy
[03:51] <ogra> would be something we could drop (it would be sane for the pacage to be in universe) 
[03:51] <ogra> seb128, lfittl i guess ;)
[03:51] <seb128> ogra: no, kagou
[03:51] <ogra> heh, ok
[03:51] <ogra> thats why i had a pm open this morning from him :)
[03:51] <seb128> hehe
[03:52] <seb128> maybe we should look at tackle that cdbs bug pointed by doko
[03:52] <LarstiQ> upgrading to 2.42 would be nice, if possible
[03:52] <ogra> well, blender has a big prob now it totally depends on ffmpeg, i considered dropping it already, but that wil get me many user complaints
[03:52] <seb128> the one which make every binary from a same source package ship the ChangeLog, etc
[03:52] <seb128> that could spare some megas
[03:53] <doko> which reminds me at ajmitch's missing cdbs upload ...
[03:54] <ogra> doko, that was the fix for the new python policy stuff, right ? if so, we have that anyway, i fixed it weeks ago
[03:54] <Kamion> looks like vim currently requires /usr/share/vim/vim70/lang to stay where it is
[03:55] <doko> ogra: no, new sync is required, and according to pitti, ajmitch has one prepared, but not submitted
[03:56] <ogra> ah, k
[03:57] <janimo> seb128: I have asked before, but any new opinions on splitting at least some libs out of gnome-python{-extras} to separate binary packages?
[03:57] <ogra> ok, i'll let blender go bac to universe
[03:57] <ogra> *back
[03:57] <seb128> janimo: I don't want to
[03:57] <janimo> g-a-i only needs gtkhtml2 but installs a lot besides that because of the bindsings
[03:57] <seb128> janimo: or get them splitted from Debian
[03:58] <janimo> seb128: but are you not mainatining them in debian anymore?
[03:58] <seb128> janimo: they are team maintained and I'm pretty busy atm so other people are likely to give you a better reply
[03:59] <janimo> seb128: in #debian-devel or is there a more appropriate channel?
[03:59] <dholbach> #gnome-debian on irc.gimp.net
[03:59] <janimo> and which of thos euploadrs is more likely to be involved with this package?
[03:59] <seb128> janimo: bug report or #gnome-debian on GIMPNet
[03:59] <janimo> dholbach: ok thanks
[03:59] <janimo> seb128: thanks
[04:02] <seb128> janimo: you probably want to mention you speak about python
[04:02] <janimo> seb128: good idea ;)
[04:11] <herzi_x41> mjg59: can you take a quick look at https://launchpad.net/distros/ubuntu/+source/spiftacity/+bug/57843
[04:11] <Ubugtu> Malone bug 57843 in spiftacity "rebuild or merge with metacity" [Untriaged,Unconfirmed]  
[04:11] <herzi_x41> thanks
[04:12] <Mithrandir> hiya Hobbsee
[04:12] <Hobbsee> hey Mithrandir, how are you doing?  :)
[04:13] <seb128> herzi_x41: I had a look at that yesterday, but activating composite with metacity make it unusable (sort of blue,purple background with a sort of reduced ressource mode, I had to reboot to rescue mode and downgrade to the edgy version to be able to use my desktop again)
[04:13] <Hobbsee> woo!  i got my name in another debian changelog :)
[04:14] <seb128> Hobbsee: forwarding .desktops now? :)
[04:14] <Hobbsee> seb128: i did for one package, i think.
[04:14] <seb128> herzi_x41: and I'm reluctant making metacity linking to a lib with no ABI stability
[04:14] <Hobbsee> seb128: no, i kept harrassing allee to fix his package in debian so i could sync it.
[04:14] <bddebian> *cough*desktops*cough*
[04:14] <seb128> Hobbsee: I've read your name to a package that included the .desktop you forwarded I think
[04:15] <Hobbsee> seb128: yeah, quite likely. 
[04:15] <Hobbsee> bddebian: no, it was +    Thx Hobbsee for reminding me (again and again :).
[04:15] <Hobbsee> about kdelibs-bin dependancy that needed to be axed.
[04:15] <seb128> Hobbsee: 
[04:15] <seb128> " epiphany (0.5.1-4) unstable; urgency=low
[04:15] <seb128>  .
[04:15] <seb128>    * Add desktop file used by Ubuntu from the original patch sent
[04:15] <seb128>      by Sarah Hobbs <hobbsee@kubuntu.org>"
[04:16] <Hobbsee> seb128: ah yes, i got an email from him today
[04:16] <Hobbsee> > +++ 0.5.1-3ubuntu1/debian/dirs	2006-07-10 11:18:27.000000000
[04:16] <Hobbsee>   This file (dirs) doesn't exist in debian 0.5.1-3 version, arch
[04:16] <Hobbsee> independent data has been splitted in a separate package, so same
[04:16] <Hobbsee> happened to dirs file. You may want to update the ubuntu version to
[04:16] <Hobbsee> reflect it.
[04:16] <ogra> wohoo, Hobbsee on her way to become DD 
[04:17] <Hobbsee> ogra: hah.   no way
[04:17] <ogra> well, you partially entered the gnome team in debian with that change :P
[04:17] <Hobbsee> ogra: presumably i should go for core (again) before that?
[04:17] <Hobbsee> ogra: argh.  i dont even use gnome.
[04:17] <ogra> hehe, i know :)
[04:18] <ogra> we'll get you there ;)
[04:18] <Hobbsee> hah
[04:18] <Hobbsee> dream on
[04:18] <ogra> *g*
[04:18] <bddebian> Hobbsee: Why not?  Might be your "fast path" to core-dev.. ;-P
[04:18] <Hobbsee> bddebian: my fast path?  heh
[04:18] <Mithrandir> Hobbsee: much better today than yesterday, but waiting for stuff to build is annoying.
[04:18] <Hobbsee> Mithrandir: true that
[04:20] <bddebian> Heya pygi
[04:20] <pygi> heya bddebian 
[04:24] <jcole> any xgl package maintainers or developers in this room?
[04:27] <seb128> jcole: don't ask to ask, just ask
[04:27] <seb128> jcole: I'm not technically maintaining it but I might be able to reply to a question
[04:27] <seb128> same for other people too
[04:27] <jcole> i've got a custom kernel and rebuild the dri module package from beerorkid ... i've installed them and it doesn't seem to work right
[04:27] <jcole> apt-get build-dep linux-dri-modules-common; apt-get source linux-dri-modules-common; cd linux-dri-modules-2.6.15-26-20060726; dpkg-buildpackage -rfakeroot
[04:28] <jcole> that builds all the linux-dri-modules-2.6.15-26-* packages and such
[04:29] <jcole> is there something i'm missing? i dist-upgraded beforehand
[04:29] <seb128> what "doesn't work right"?
[04:30] <pygi> siretart, poke? :)
[04:30] <Kamion> Mithrandir: do you know if there's a way to disable just the apt upgrade part of update-notifier, but not stuff like apport?
[04:30] <Kamion> Mithrandir: 'cos I'd like to have update-notifier running on the live CD so that apport works
[04:31] <dholbach> have a nice evening
[04:31] <bddebian> Later dholbach
[04:32] <jcole_nodri> seb128: can't get dri... it works with stock ubuntu kernel and binary modules from beerorkid
[04:32] <jcole_nodri> (EE) I810(0): [drm]  drmAddMap(front_handle) failed. Disabling DRI
[04:32] <seb128> jcole_nodri: I don't know, but doesn't looks like an Ubuntu bug if it works with the ubuntu kernel
[04:33] <jcole_nodri> seb128: is that the only package i need to rebuild? do i need to rebuild the xorg/mesa drivers and such too?
[04:34] <seb128> jcole_nodri: no idea, I'm not really a kernel nor xorg guy, maybe rodarvus knows about that
[04:36] <rodarvus> jcole_nodri, where do you got your kernel source from?
[04:36] <jcole_nodri> this is my /var/log/Xorg.0.log --> http://pastebin.ca/153243
[04:36] <rodarvus> our kernel packages have updated agpgart & drm, needed for proper DRI
[04:38] <jcole_nodri> rodarvus: from the ubuntu mirrors
[04:39] <rodarvus> "I've got a custom kernel and rebuild the dri module package from beerorkid"
[04:39] <jcole_nodri> rodarvus: apt-get source linux-source-2.6.15
[04:39] <rodarvus> what is beerorkid?
[04:40] <rodarvus> (and why did you need to download/built dri stuff from this external repository)
[04:40] <jcole_nodri> rodarvus: the dri source actually comes from http://ubuntu.compiz.net/
[04:40] <rodarvus> oh, right
[04:41] <rodarvus> I suppose they already have working DRI for dapper, isn't this true? (though, as I don't use their repos, I can't confirm this)
[04:41] <jcole_nodri> rodarvus: the dri in dapper is almost 3 years old for my intel card
[04:42] <jcole_nodri> rodarvus: many glx extensions have been added in the last few years (including the ones xgl/compiz needs)
[04:43] <rodarvus> indeed, intel dri on dapper is seriously lacking
[04:43] <rodarvus> (but unfortunately, its nothing we can officially deal with right now, since dapper is released, and this is not something that could go into dapper-updates too)
[04:44] <Hobbsee> hehe
[04:44] <ogra> heh
[04:44] <rodarvus> people, you are evil.
[04:44] <rodarvus> :)
[04:44] <Hobbsee> us, evil?
[04:45] <janimo> rodarvus: is X version frozen for edgy?
[04:45] <janimo> as is no 7.2 for sure
[04:45] <rodarvus> janimo, since a few weeks, yes
[04:45] <rodarvus> no 7.2 for Edgy :)
[04:45] <herzi_x41> janimo: 7.2 gets out after edgy, doesn't it?
[04:46] <rodarvus> 7.2 will be released in two months, (maybe more)
[04:46] <rodarvus> so, about 20 days before edgy is released
[04:46] <rodarvus> surely not in time for inclusion into edgy
[04:46] <janimo> ok I though they planned sep but anyway
[04:46] <rodarvus> janimo, ~ october 15-20, afaik
[04:46] <rodarvus> surely in time for Edgy+1
[04:47] <janimo> rodarvus: do X packages come via debian now or is x-swat handling them?
[04:47] <rodarvus> there's plenty of cool stuff which can be done for X.Org on Edgy+1
[04:47] <jcole_nodri> rodarvus: like dri
[04:47] <janimo> rodarvus: re the amd OLPC driver are you planning to package it or waiting on debian?
[04:47] <rodarvus> janimo, I wish they could mostly be handled by debian, but unfortunately we (x-swat) had to mostly drive them for edgy
[04:47] <rodarvus> janimo, I'll package it
[04:48] <janimo> ok
[04:48] <rodarvus> later this week
[04:48] <rodarvus> sorry for not answering your email on the subject, btw :)
[04:48] <janimo> np
[04:48] <rodarvus> jcole_nodri, we package dri
[04:49] <rodarvus> theres plenty of coolness coming for X.Org on edgy and edgy+1 (more if we find the right person to hire)
[04:50] <Hobbsee> rodarvus: you're not volunteering?  :P
[04:50] <jcole_nodri> rodarvus: who packages the linux-dri-modules-* packages?
[04:50] <rodarvus> X.Org is not the reason I was hired. The only reason I'm doing it is because we don't have another hacker working full time on it
[04:51] <jcole_nodri> whoa "who packages the packages"
[04:51] <rodarvus> jcole_nodri, there is no linux-dri-modules-* package on (official) dapper
[04:51] <infinity> Kamion: Nice CD health check mails.
[04:51] <Hobbsee> rodarvus: i realise that :)  i was joking
[04:51] <Hobbsee> hi infinity 
[04:51] <infinity> Kamion: Also, FWIW, I've already pinged doko about fixing python-tk brokenness.
[04:51] <rodarvus> these modules are inside the regular kernel package, and are done by the ubuntu-kernel team
[04:51] <Kamion> infinity: good good. I hadn't got there yet ...
[04:51] <HiddenWolf> rodarvus: so, are there any takers for it? You blogged about the employment ad. ;)
[04:51] <jcole_nodri> rodarvus: does edgy have newer dri than dapper?
[04:52] <Kamion> infinity: I'll add stuff like livefs build status to those mails later; I just got bored before doing so
[04:52] <Kamion> infinity: does the reformatting I did of britney output suit you?
[04:52] <rodarvus> HiddenWolf, I'm not interviewing people for this position, so, I have no idea, really
[04:52] <infinity> Kamion: It doesn't make me want to poke my eyes out or anything.
[04:52] <Kamion> I compacted multiple architectures down onto a single line, per mdz's suggestion
[04:53] <infinity> Kamion: Yeah, works well enough for me.
[04:56] <jcole_nodri> rodarvus: if so, i'll yank and rebuild the edgy kernel sources instead
[04:58] <janimo> Kamion: nice mail indeed, could you add Gloubiboulga to the Cc as well for xubuntu?
[05:02] <Kamion> janimo: sure, done - I was going to ask you about it beforehand but never seemed to catch you on IRC
[05:03] <janimo> Kamion: yes, I was mostly offline these past weeks
[05:03] <janimo> thanks
[05:03] <Kamion> janimo: you ok with those being sent daily?
[05:03] <Kamion> as I said to infinity, I'll flesh them out a bit later
[05:03] <janimo> Kamion: re a11y boot entry, one will be needed for the xubuntu desktop CD as well, I assume you are doing them for the ubuntu CD?
[05:03] <janimo> Kamion: daily is fine
[05:04] <Kamion> janimo: easy to do - is the code in casper yet?
[05:04] <janimo> Kamion: no idea about what code should that be sorry. It's ok to have that once the Ubuntu CD is accesbile just wanted to make sure it;'s you I'll come to
[05:05] <janimo> I think it's not yet in casper as I gathered from what henrik blogged today
[05:05] <Kamion> oh, you just use gtk so I guess it's not hard
[05:05] <Kamion> do you have gconftool?
[05:05] <janimo> Kamion: yes
[05:05] <Kamion> if so, it should just be a matter of adding the necessary applications
[05:05] <janimo> and added two metapackes to ship which dep on orca & co
[05:06] <Kamion> janimo: hmm - you should have the a11y entry already
[05:06] <Kamion> janimo: it's not really a boot menu entry, it's a full menu down at the bottom right of the gfxboot screen
[05:06] <janimo> Kamion: I admit I have not tried an edgy live as they were oversized until recently
[05:07] <Kamion> janimo: and it's added unconditionally for all derivatives - has been since dapper
[05:07] <Kamion> which was actually a bug for kubuntu, but never mind since they're making it work now
[05:07] <janimo> ah, I though it was supposed to be a main entry. ok then
[05:08] <janimo> so then i tmeans it has to have some extra packages associated or a way to tell it to start and then install some gnome apps besides the xubuntu ones
[05:09] <Kamion> it doesn't cause anything extra to be installed, only stuff to be enabled
[05:09] <janimo> it is different from ubuntu as it does not install orca and gnome-mag by default
[05:09] <Kamion> see scripts/casper-bottom/*accessibility in casper
[05:09] <Kamion> that's the code that actually implements those menu items
[05:09] <Kamion> if you need certain menu items disabled for xubuntu, let me know
[05:09] <janimo> the a11y apps are not in the default xubuntu-desktoip so soemthing extra may be needed for the xubnunt CD then?
[05:09] <Kamion> yeah, if you want
[05:10] <Kamion> if they're not usable for xubuntu, we can disable those a11y options for you
[05:10] <janimo> Kamion: I think they should be usable but are not put in the default desktop since they are relatively large gnome deps
[05:11] <Kamion> nod
[05:11] <janimo> so rigth now that option in ubuntu causes casper to call gconftool and tweak the desktop on start
[05:11] <Kamion> right
[05:11] <janimo> whereas in xubuntu it woulkd need that + install a few extra packages besides xubuntu-desktop for that to make sense
[05:12] <janimo> packages starting xubuntu-at which are in the ship seed now
[05:15] <Hobbsee> hey Arbiter 
[05:16] <Arbiter> heya Hobbsee 
[05:16] <ogra> AAAAAAAAAAHHHHHHHHH
[05:17] <Hobbsee> hehe
[05:17] <ogra> Hobbsee, THATS COLD !!
[05:17] <Arbiter> o.O?
[05:17] <Hobbsee> ogra: yes, and?
[05:17] <Hobbsee> Arbiter: [01:14]  * Hobbsee drops icecubes down ogra's back, to keep him from getting bored.
[05:17] <ogra> not again !
[05:17] <Arbiter> 
[05:17] <Hobbsee> ogra: what's the problem?  you're in the northern hemisphere, anyway.
[05:18] <ogra> its cold, windy and raining here today
[05:18] <ogra> 14C
[05:18] <Hobbsee> ogra: hah.
[05:18] <ogra> not the weather for icecubes running down your back ... :)
[05:18] <Hobbsee> ogra: sure sure...
[05:19] <ogra> i'm happy one of the cats warms my feet atm
[05:20] <thom> Hobbsee: good luck with that one
[05:21] <Hobbsee> hehe
[05:21] <Kamion> janimo: mm, that's not really feasible though
[05:21] <Kamion> janimo: especially not on the live CD, where this would have to be happening at boot
[05:22] <Kamion> janimo: on the install CD I guess it would be theoretically doable but we have no infrastructure for it at present
[05:24] <janimo> Kamion, so on the liveCD we should install all the accessibility stuff if we want it from start
[05:24] <janimo> is there a way of not installing it on the disk if it was not enabled then?
[05:24] <janimo> so the gnome deps only show up in the live session
[05:25] <Zdra> seb128: for the icon problem in notification bubble, I found this patch from gentoo: ftp://ftp.belnet.be/linux/gentoo-portage/x11-misc/notification-daemon/files/notification-daemon-0.3.5-icon-data.patch
[05:26] <slomo> Zdra: which problem? :)
[05:26] <Zdra> images doesn't appear in notify bubbles
[05:27] <Zdra> that's a strange bug, with dbus 0.60 from dapper it works
[05:27] <slomo> Zdra: ok, i noticed this lately too... it's still the case with dbus 0.92 on edgy
[05:27] <Zdra> and with this gentoo patch it seems to work too, at least that's what an user told me
[05:28] <slomo> Zdra: could you file a bug on notification-daemon with this patch and assign it to me? i'll take a look later
[05:28] <Zdra> slomo: ok thanks
[05:29] <robtaylor> :q
[05:30] <Kamion> janimo: that could be arranged with the aid of live-cd-stacked-filesystems, I think
[05:30] <Kamion> janimo: probably best to include only the ones that don't need gnome for now
[05:32] <Zdra> slomo: https://launchpad.net/distros/ubuntu/+source/notification-daemon/+bug/58114
[05:32] <Ubugtu> Malone bug 58114 in notification-daemon "image doesn't appear in bubbles" [Untriaged,Unconfirmed]  
[05:35] <slomo> Zdra: the patch is from upstream svn... and explicitely says that it makes icons work again on dbus >= 0.61... nice catch :)
[05:36] <janimo> Kamion: all a11y stuff needs gnome so we'll have to wait for the stacked fs stuff if that solves it
[05:37] <janimo> or we could just add it now to test a11y and hope we'll fid a way to remove it from the install later in the cycle
[05:37] <janimo> that may be even better to get them tested in xfce
[05:38] <janimo> I did not do that so far since I somehow thought that addtional packages can be installed based on boot selection
[05:38] <janimo> it worked for the alternate CD and forgot they are quite different
[05:39] <janimo> is anyone else experiencing firefox not handling https urls?
[05:39] <janimo> the wiki and LP among them
[05:40] <Riddell> hmm, these CDs really have got larger
[05:41] <ogra> yep
[05:41] <ogra> all of them ....
[05:41] <ogra> *bigsigh*
[05:41] <wasabi_> Hmm. My xkb has been acting up for the last week or so. Any body aware of changes which could have effected it? gnome-settings-d is unable to set it up. setxkbmap says it can't interpret _XKB_RULES_NAMES.  Latest packages haven't fixed it.
[05:42] <wasabi_> Also, if anybody can explain to me htf XKB operates I'd be in debt, so I could find the problem myself. ;)
[05:42] <Kamion> janimo: did it really work for the alternate CD? I don't recall ever adding code to d-i that installed packages based on access=
[05:42] <Mithrandir> wasabi_: what does setxkbmap -print output?  (pastebin or query, please)
[05:42] <Kamion> or in fact that did pretty much anything at all based on access=
[05:42] <janimo> Kamion: maybe not via d-i ut I thought the LTSP extra packages were added in that way
[05:42] <Kamion> ltsp has a special udeb that does the work
[05:43] <Kamion> it would be possible to do so for access too, although nobody has yet
[05:57] <slomo> Zdra: yep, fixes it for me... do you want to test it too?
[05:57] <slomo> Zdra: (i took the patch from upstream svn instead of the gentoo one)
[05:58] <Zdra> slomo: I'm a bit busy atm I'll try to test it later today if possible and if you didn't commit before ;-)
[05:59] <Zdra> but if it works for you, for gentoo users and for upstream I guess it will work for me too ;-)
[06:00] <slomo> Zdra: ok... i tested it on my two machines here and it works fine... i uploaded it, if you still have any issues please tell me :)
[06:00] <Zdra> slomo: ok
[06:00] <Zdra> thanks !
[06:01] <slomo> np :)
[06:02] <seb128> Zdra, slomo: thank you for working on that n-d bug ;)
[06:03] <slomo> seb128: i also included a patch for fixing the assertion failure that mvo worked around last week, do you remember?
[06:03] <seb128> slomo: nop, I just though mvo make the code no stop on assertions to workaround it
[06:03] <seb128> slomo: but I've had mails issues during the sprint so didn't notice all the changes from previous week
[06:04] <slomo> seb128: yes... now the assertion (well, the only assertion i ever got... not sure if it's really the same) is gone
[06:05] <seb128> slomo: good job ;)
[06:45] <ogra> hmm
[06:46] <Burgwork> ogra, ?
[06:55] <Kamion> ogra: perhaps you were just a bit too quick on the trigger?
[06:55] <ogra> heh, well
[06:55] <ogra> likely
[06:56] <ogra> new edubuntu meta was on a.u.c though
[06:56] <ogra> (binaries)
[06:56] <Kamion> ogra: what should have been added?
[06:56] <ogra> removed ...
[06:56] <Kamion> or removed
[06:56] <ogra> i merged the ppd drop from ubuntu and dropped blende
[06:56] <ogra> r
[06:57] <ogra> should have gained at least 17MB
[06:57] <Kamion> ogra: what version of edubuntu-meta?
[06:57] <ogra> 1.7
[06:57] <Kamion> ok, that was used
[06:58] <ogra> hmm
[06:58] <ogra> then its weird 
[06:59] <ogra> + Trying to add foomatic-filters-ppds...
[06:59] <ogra> from the log ...
[07:00] <Kamion> something is wrong with my seed checkouts on rookery
[07:00] <Kamion> cjwatson@rookery:~/public_html/seeds/edubuntu-edgy$ bzr pull
[07:00] <Kamion> Using saved location: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.edgy/
[07:00] <Kamion> 0 revision(s) pulled.
[07:00] <Kamion> cjwatson@rookery:~/public_html/seeds/edubuntu-edgy$ bzr revno
[07:00] <Kamion> 511
[07:00] <Kamion> but the current revno should be 515
[07:01] <ogra> right
[07:01] <ogra> wich the metapackage update script apprently got ...
[07:01] <Kamion> oh, it looks like the http supermirror is broken
[07:01] <ogra> so the seeds are fine
[07:01] <Kamion> remember that the metapackage update script uses sftp
[07:02] <ogra> and cdimage ? wget ? 
[07:02] <Kamion> er, a complicated chain of stuff, but ultimately bzr pull from http
[07:02] <ogra> the logs look like you are making a local copy
[07:02] <ogra> ah
[07:02] <Kamion> don't get distracted :) that's not relevant
[07:03] <Kamion> ogra: would you mind chasing this up with #launchpad? the problem is that the http mirror of /~ubuntu-core-dev/ubuntu-seeds/edubuntu.edgy is out of date
[07:03] <ogra> oki
[07:03] <Kamion> thanks
[07:24] <jcole> -26? http://packages.ubuntu.com/edgy/misc/vmware-player-kernel-modules-2.6.15-23
[07:24] <jcole> err.. http://packages.ubuntu.com/edgy/misc/vmware-player-kernel-modules
[07:25] <jcole> maybe those should be merged with restricted modules...
[07:42] <Trae> https://launchpad.net/distros/ubuntu/+bug/22336  Anyone know when this is going to get addressed?  This is a fairly nasty bug that seems to affect all laptops.
[07:42] <Ubugtu> Malone bug 22336 in Ubuntu "laptop overheats when performing CPU intensive tasks." [High,Needs info]  
[07:44] <Trae> Having all Ubuntu laptops shut off when they do any real CPU work doesn't seem like it would be a good thing.
[07:45] <tseng> "If the fan is running at full speed and yet the CPU is overheating, I don't see
[07:45] <tseng> how this can be the fault of the operating system"
[07:46] <tseng> you don't need to comment on bugs here btw, the bug is clearly the best place
[07:46] <Trae> tseng, It's been open for almost a year.
[07:46] <Trae> at what point does someone need to make a comment on it?
[07:46] <Trae> and where?
[07:46] <Keybuk> Trae: dude, "affect all laptops" is somewhat of an exaggeration
[07:46] <Trae> Keybuk, do you have a laptop?
[07:47] <slomo> Trae: at least my laptop is not affected by this
[07:47] <tseng> (I was not going to feed the troll on that one)
[07:47] <Keybuk> Trae: yes, several
[07:47] <tseng> 80C is really freaking hot if you didn't know
[07:47] <Treenaks> 
[07:47] <Treenaks> ~/.
[07:47] <tseng> my pentium 4, legendary for heat output, runs at 45
[07:47] <Treenaks> uhr, oops, sorry
[07:47] <Keybuk> there's an old kernel bug that nobody's figured out that means your laptop wildly over-estimates how hot it is
[07:48] <Keybuk> so it isn't over-heating, but is just the kernel getting the math wrong
[07:49] <Trae> Keybuk, would would other Distro's not have this problem?  That's the odd thing
[07:49] <Trae> err s/would/why/
[07:49] <Trae> heh
[07:49] <Keybuk> Trae: we tend to pull the latest acpi patches, could be in there
[07:49] <Keybuk> there's some chatter on the bug that suggests it also could be powernowd buggering up -- if you try disabling that, does it still power down?
[07:49] <Trae> Keybuk, k, I would just hope this would be fixed for Edgy
[07:50] <Trae> Keybuk, nod.. I did try that.. and *boom*
[07:50] <Trae> hmmm
[07:50] <Trae> wait
[07:50] <Trae> maybe I tried turning off acpi
[07:50] <Trae> Keybuk, how do you disable powernowd ?
[07:50] <Keybuk> Trae: /etc/init.d/powernowd stop
[07:50] <Trae> nod
[07:51] <Trae> hehe, just tried that
[07:51] <Trae> ok... let me fire up something and see if this sucker dies
[07:51] <Trae> If I go poof, that means no ;)  {it didn't work}
[07:56] <Trae> finally found a long enough video...
[07:56] <jcole> Trae: tail -f /var/log/messages | grep -i acpi
[07:56] <Trae> k
[07:57] <Trae> jcole, hmm nothing is showing up.
[07:57] <Trae> that a good or bad thing?
[07:57] <Trae> heh
[07:59] <jcole> Trae: tail -f /var/log/acpid
[07:59] <Trae> ok
[07:59] <Trae> [Mon Aug 28 01:01:47 2006]  completed event "battery BAT0 00000081 00000001"
[08:01] <Trae> Keybuk, hmmm
[08:01] <Trae> Keybuk, stillll going!
[08:01] <Trae> normally this sucker would have shut off by now
[08:01] <lfittl> elmo: ping
[08:02] <elmo> lfittl: ?
[08:02] <lfittl> elmo: did you get my mail about gnupg and the smartcard reader udev rules? (sry for asking again here, it's just that FF comes closer and closer ;))
[08:03] <elmo> lfittl: I'm not a maintainer of packages in ubuntu - whatever happens to gnupg in ubuntu isn't my problem/concern
[08:03] <Trae> it seems like powernowd is the culprit
[08:03] <jdong> Keybuk: thanks for pushing through all the backports. I really appreciate it
[08:03] <Trae> I'll post something to the bug letting people know how they can fix things...
[08:03] <Trae> Keybuk, this is working so far and no shutdown, thanks tons.
[08:04] <lfittl> elmo: sure, but as you maintain it in debian I thought you might want to take a look at my solution, as I am interested in getting it into Debian sometime
[08:07] <lfittl> elmo: and also, I was not sure if gnupg is the right package for it, or if there should be a dedicated package "gnupg-udev"
[08:07] <elmo> a new package sounds like overkill, I'm not sure gnupg is the right p ackage thought
[08:07] <elmo> s/t$$/
[08:08] <lfittl> any idea which package would be better?
[08:09] <Trae_> Keybuk ooops.  Spoke too soon.
[08:09] <Trae_> Keybuk about 6mins into the second video it shut off.... which is way longer than it normally would work.  (2 or 3 mins before and it'd shut off)
[08:10] <Trae_> this was after playing a YouTube video for around 12mins it powered off.
[08:11] <Keybuk> Trae: hmm, interesting
[08:11] <Keybuk> ok, what happens if you disable powernowd and then also
[08:12] <Trae> what was that tail command from before?  (no longer have history :(
[08:12] <tseng> 13:56 < jcole> Trae: tail -f /var/log/messages | grep -i acpi
[08:12] <Trae> tseng danke
[08:13] <Keybuk> sudo sh -c 'echo -n demand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor'
[08:13] <Trae> Keybuk yessir... you were saying?
[08:13] <Trae> ahh 
[08:14] <Trae> Keybuk I don't have scaling_govenor
[08:15] <Trae> oh wait
[08:15] <Trae> sorry
[08:15] <Trae> typo
[08:17] <Trae> keep typing something wrong I think.. let me get on irc again and paste it to myself as a msg
[08:18] <Trae> hmm
[08:18] <Trae> I get this Keybuk:
[08:18] <Trae> line: 0 echo write error invalid argument
[08:19] <Keybuk> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
[08:19] <Trae2> k
[08:19] <Trae2> I have:
[08:20] <Trae2> userspace powersave ondemand conservative performance
[08:20] <Keybuk> oh, sorry
[08:20] <Keybuk> echo -n ondemand :)
[08:20] <Keybuk> thinko
[08:20] <Trae> okies... heh, got this here so I could cut and paste
[08:20] <Trae> ;)
[08:21] <Trae> ok
[08:21] <Trae> that took
[08:21] <Trae> power off powernowd and try again?
[08:21] <Keybuk> power off powernowd first
[08:22] <Trae> http://www.shorttext.com/ab7ny
[08:22] <Robot101> does powernowd predate ondemand?
[08:22] <Trae> fwiw
[08:23] <Trae> ok, I did that... did powernowd stop && the other comamnd you gave me with ondemand
[08:23] <Trae> and that seemed to take
[08:23] <Trae> Keybuk, anything else ?
[08:23] <Keybuk> no, try that
[08:23] <Trae> okies
[08:25] <Trae2> ok.. here we go
[08:25] <Trae2> Keybuk anything I should be tailing?
[08:26] <Keybuk> Trae: /var/log/dmesg may be interesting
[08:26] <Trae2> k
[08:28] <Trae2> is there a way I can monitor temp?
[08:28] <Keybuk> watch "acpi -V"
[08:29] <Trae2> k
[08:29] <Trae2> 63
[08:29] <Trae2> Keybuk mind if I /q you these tmps?
[08:29] <Keybuk> sure
[08:55] <Mithrandir> janimo: are you aware that we're getting close to a new knot release?  You might want to make sure that xubuntu is in good shape over the next couple of days.
[08:55] <janimo> Mithrandir: yes aware that it is planned for Thu
[08:55] <janimo> will test it tomorrow
[08:55] <janimo> Gloubiboulga: started testing otday as well
[08:56] <Mithrandir> janimo: goodie; just wanted to make sure you were aware of it.
[08:56] <crimsun> the daily seems fine here fwiw, though I only tested clean and not a dist-upgrade.
[08:56] <lucas> is the switch from powernowd to the ondemand cpufreq governor considered for edgy, for systems which support ondemand ?
[08:57] <lucas> I was reading the paper from OLS about ondemand, and it really looks impressive
[08:59] <jdong> lucas: I'm not sure
[08:59] <jdong> but ondemand is what I use :)
[09:00] <jdong> it's much more responsive than powernowd
[09:00] <lucas> what's the clean way to switch from powernowd to ondemand ?
[09:00] <jdong> but that's gonna require some rewiring at the acpi-support level
[09:00] <jdong> remove powernowd
[09:00] <Keybuk> I meant to chat to mjg59 about that at the weekend
[09:00] <jdong> I currently just hacked /etc/acpi/power.sh
[09:01] <lucas> ok
[09:01] <jdong> make sure your cpufreq modules are probed in
[09:01] <jdong> either via /etc/modules or do it in power.sh, too
[09:01] <lucas> I was more wondering about edgy than about my own laptop
[09:02] <jdong> right
[09:02] <jdong> I hope to see edgy switch away from powernowd
[09:02] <jdong> for yourself, you can actually just use ac.d and battery.d in /etc/acpi
[09:02] <jdong> no need to butcher power.sh
[09:03] <jdong> but Keybuk, pretty please follow up on ondemand for edgy :)
[09:03] <jdong> or at least make powernowd poll more frequently
[09:03] <lucas> the problem is that ondemand requires many more switches than powernowd
[09:03] <lucas> so it's inefficient with processors without fast freq switching
[09:03] <jdong> speedsteps need to be blacklisted
[09:04] <jdong> most modern CPU's switch pretty fast
[09:04] <jdong> enough that you don't notice
[09:04] <jdong> but I can see needing branching code and cpu detection :-/
[09:04] <jdong> which leads me to believe it won't be ready for edgy
[09:04] <jdong> for sure any pentium M / core duo can be whitelisted
[09:05] <jdong> and I'm pretty sure most turion / athlon64 are fine
[09:05] <jdong> but celeron M's are not for sure
[09:05] <jdong> the ones that scale from 300MHz up to 1.xGHz
[09:05] <jdong> they lag horribly on ondemand
[09:19] <zyg1> hey
[09:21] <clee> is there a channel for the hwdb?
[09:21] <sladen> clee: /query ogra
[09:21] <clee> sladen: ah, that was the nick! thanks.
[09:33] <Trae> Keybuk, thank you again for your time on this matter.  You have been most helpful, courteous and attentative. :)
[09:34] <Trae> Keybuk, quick question... any way I can make these changes "stick" between reboots?  Like, how can I safely disable powernowd "The Ubuntu Way" so I don't break things?
[09:35] <Trae> and will that ondemand echo thingy you had me do hold after a reboot, or will it require some special attention too?
[09:35] <Keybuk> Trae: for now, I'd just edit the top of /etc/init.d/powernowd; add the echo and exit 0 :p
[09:35] <Keybuk> or
[09:37] <Keybuk> rm /etc/rc2.d/S??powernowd
[09:37] <Keybuk> and add the echo to /etc/rc.local
[09:37] <Keybuk> actually, yeah, do the latter
[09:37] <Keybuk> there's module loading in the powernowd.early script you need
[09:38] <Trae> Keybuk, do those bugs close?  Meaning, once they are marked fixed are they gone, or are they kept in an archive for historic purposes on launchpad?
[09:38] <Keybuk> kept for historical purposes, but marked as closed
[09:38] <Trae> k
[09:39] <Trae> I could just add the two commands to /etc/rc.local at boot right?
[09:39] <Trae> I've not used it in eons
[09:39] <Keybuk> right
[09:40] <Trae> after the esac thingy 
[09:40] <Keybuk> esac ?
[09:40] <Trae> fwiw, I do Graphics with Linux... I don't code, soo... if I sound uninformed, that's the reason why :)
[09:41] <Trae> it's at the end of the /etc/init.d/rc.local 
[09:43] <Keybuk> Trae: I know, we've actually met
[09:43] <Trae> Keybuk, we have?
[09:43] <Trae> Keybuk, uh oh
[09:43] <Trae> :)
[09:43] <Keybuk> Trae: ahh, /etc/rc.local not /etc/init.d/rc.local (the latter runs the former)
[09:43] <Keybuk> Trae: LWE 1999, iirc
[09:43] <Trae> Keybuk, sweet.... that was a great show
[09:44] <Trae> all the linux.com banners all over San Jose
[09:44] <Trae> hehe
[09:44] <Keybuk> I used to run segfault.org :p
[09:44] <Trae> what was your nick then?
[09:44] <Keybuk> still Keybuk
[09:44] <Trae> omg
[09:44] <Trae> Scott!!
[09:44] <Trae> hahaha
[09:44] <Trae> You should have said it was you. :P
[09:44] <Trae> I never know you by Keybuk
[09:45] <Keybuk> hehe
[09:45] <Trae> but immediately recognized SJR ;)
[09:45] <Trae> from the whois
[09:45] <Trae> hmm, didn't I bug  you via email recently?  *chuckle*
[09:45] <Keybuk> umm, it's possible
[09:46] <Trae> at any rate, /me hunts for /etc/rc.local
[10:09] <ogra_> lfittl, hey ... blender moves to universe ....
[10:09] <ogra_> so have fun with it :)
[10:10] <lfittl> ogra_: very nice, how come?
[10:11] <ogra_> space probs on th edubuntu CD
[10:11] <ogra_> edubuntu was what kept it in main ...
[10:11] <ogra_> it should move to universe during this week ....
[10:11] <lfittl> will get 2.42a synced/merged after it is back to universe :)
[10:12] <jdong> Keybuk: ping
[10:12] <Keybuk> jdong: hey
[10:12] <jdong> Keybuk: the latest k3b backport was "rejected" from the archive
[10:12] <jdong> k3b: Version newer than that in BACKPORTS. 0.12.17-1ubuntu2~dapper1 >= 0.12.16-1ubuntu3~dapper1
[10:12] <jdong> :-/
[10:13] <Keybuk> right ... ?
[10:13] <jdong> I meant to have the new 0.12.17 backport replace the 0.12.16 backport that did not build
[10:14] <jdong> does the current backports system not work that way?
[10:14] <Keybuk> you'll have to be a bit more verbose, sorry
[10:14] <Keybuk> I did a backport of k3b for you
[10:14] <Keybuk> and that has been rejected because there was already a backport in the archive?
[10:14] <jdong> right
[10:14] <Keybuk> was the backport-in-the-archive version higher or lower than the one I did?
[10:14] <jdong> the one in the archive was lower 
[10:15] <Keybuk> ok
[10:15] <Keybuk> and it rejected?
[10:15] <jdong> right
[10:15] <Keybuk> soyuz bug then
[10:15] <jdong> k :)
[10:15] <Keybuk> please file a bug in launchpad
[10:15] <jdong> where in launchpad?
[10:15] <Kamion> /products/soyuz
[10:15] <jdong> k
[10:15] <HiddenWolf> +filebug
[10:15] <HiddenWolf> ;)
[10:15] <Kamion> ew
[10:16] <Kamion> it's got a hardcoded check for *everything* that it's not newer than whatever's in the corresponding backports pocket
[10:16] <Kamion> nobody thought to exclude backports from that check apparently :)
[10:16] <Kamion> I'm not convinced the check is a good idea anyway - if we want to supersede the backport, then tough, we want to supersede it
[10:16] <Kamion> please subscribe me to the bug you file and I'll try to explain that
[10:18] <jdong> Kamion: you are subscribed to bug 58144
[10:18] <Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58144
[10:18] <Kamion> thanks
[10:19] <jdong> and oh yeah, NEW is ok right? (for packages that are new to Edgy and backported to Dapper)
[10:19] <jdong> i.e. someone will eventually allow it through, right?
[10:22] <Kamion> well, that happened in the first round of backports and it got processed ...
[10:23] <mvo> Keybuk: did someone told you already that upstart made it onto heise.de? (I guess so, given that the news item is a couple of hours old). still nice to see
[10:23] <Keybuk> what's heise.de?
[10:23] <thom> german tech news site
[10:23] <ogra> *the* german IT news site
[10:23] <mvo> Keybuk: its the most popular german tech news site
[10:24] <schnabel> hello
[10:24] <ogra> Keybuk, http://www.heise.de/newsticker/meldung/77421
[10:25] <ogra> happy bablefishing :)
[10:25] <Keybuk> heh
[10:25] <Lure> wow, and 300 comments on the story...
[10:27] <ogra> heh, they praise the dependencies you can add through events :P
[10:31] <jordi> is edgy at upstream freeze now?
[10:31] <crimsun> for main, yes.
[10:31] <jordi> ick
[10:31] <Kamion> has been for ages
[10:31] <jordi> I guess :)
[10:31] <Kamion> we're nearly at feature freeze
[10:31] <Kamion> to my abject terror
[10:32] <jordi> oh well. nano 2.0 about to hit the streets, it'd had been nice to have the round version number
[10:32] <Keybuk> Kamion: GET CODING!
[10:33] <_ion> Talking of which, /me hasn't seen new stuff in the upstart repository for a while. ;-)
[10:33] <infinity> jordi: I doubt anyone other than the nano maintainer (pats you on the head) would much care what version it is. :)
[10:34] <jordi> infinity: heh, even I don't care too much.
[10:34] <jordi> more when I know the changes are basically translation and veeery minor nitpicks
[10:34] <jordi> (since 1.3.12)
[10:34] <infinity> jordi: Frankly, I'm shocked to discover that anything so featureless even gets upstream development, except for the occasional bitrot fixing.
[10:35] <jordi> there's plenty of stuff nano needs to get still
[10:35] <infinity> "removed from the archive"?
[10:35] <jordi> well, give vim to your average ubuntu newbie
[10:35] <infinity> "replaced by ae, we were right in 1999, damnit"?
[10:36] <_ion> jordi: A good idea. :-)
[10:36] <infinity> Yeah, vi's a poor choice for anyone who's not an old-skool UNIX hacker.  Modal editors are confusing.
[10:37] <jordi> give them gedit when xorg gets fucked up :)
[10:37] <infinity> I remember backgrounding and killing vi out of sheer frustration the first time I used it on a university machine in ~1995.
[10:37] <bddebian> hehe
[10:37] <jordi> infinity: hehe
[10:37] <infinity> And the fact that I knew how to background and kill tasks, but not exit my editor, says something.
[10:37] <thom> infinity: at least you knew how to back..
[10:37] <thom> yeah
[10:39] <ogra> grmbl ... next tim i check if a lp bug is fixed before i waste resources ... now i got three identical iso builds ...
[10:39] <HiddenWolf> ogra: one for the public, one for the archive, and one to put on the wall. ;)
[10:39] <ogra> neither will be usable :)
[10:40] <HiddenWolf> sentimental value? a reminder? ;)
[10:53] <Keybuk> mjg59: just gonna take a quick break, then can I borrow you for five minutes
[10:54] <mjg59> Keybuk: Sure
[10:54] <Keybuk> mjg59: see comment at bottom of bug #22336
[10:54] <Ubugtu> Malone bug 22336 in Ubuntu "laptop overheats when performing CPU intensive tasks." [High,Needs info]  http://launchpad.net/bugs/22336
[10:55] <mjg59> Hadn't we already decided that ondemand made more sense where possible?
[10:55] <mjg59> I've already discussed this with mdz
[10:56] <mjg59> Hang on. Let me find a Celeron and test this...
[10:57] <Keybuk> yeah I thought we had
[10:58] <Keybuk> how were you planning to decide which?
[10:58] <mjg59> Let me check the source again
[10:58] <mjg59> But I /believe/ that ondemand will fail if it won't work
[10:58] <mjg59> That is, attempting to switch the governer to ondemand will fail
[11:00] <mjg59>                 if (policy->cpuinfo.transition_latency >
[11:00] <mjg59>                                 (TRANSITION_LATENCY_LIMIT * 1000)) {
[11:00] <mjg59>                         printk(KERN_WARNING "ondemand governor failed to load "
[11:00] <mjg59>                                "due to too long transition latency\n");
[11:00] <mjg59> Right
[11:00] <mjg59>                         return -EINVAL;
[11:00] <mjg59> So try to set /sys/devices/system/cpu/*/cpufreq/scaling_governor to ondemand
[11:00] <mjg59> If that fails with EINVAL, set it to userspace and run powernowd
[11:01] <lucas> failed to load. does it mean it still shows up in scaling_available_governors ?
[11:01] <Keybuk> ok
[11:01] <mjg59> No, the failure is when it's started
[11:01] <mjg59> I think it'll still appear in the available governors
[11:01] <mjg59> Though I'm not certain of that
[11:02] <lucas> it would be easier to just grep for in in available_governors if it doesn't show up
[11:04] <mjg59> No, by the looks of it it'll still be in available_governors
[11:04] <jdong_> does preload actually make things load faster, or is it a scam like readahead most of the times :)
[11:05] <Keybuk> jdong: scam
[11:05] <Keybuk> well, it does make things a bit faster, at the cost of other things
[11:05] <bddebian> heh
[11:14] <bddebian> Keybuk: OK, wtf does ROM mean? :-)
[11:15] <Keybuk> Request-Of-Maintainer
[11:15] <bddebian> Ah..
[11:15] <Keybuk> http://ftp-master.debian.org/removals.txt
[11:15] <Keybuk> ^ cf. top of there
[11:17] <Keybuk> heh, you weren't to know
[11:17] <Keybuk> I had to ask once
[11:37] <Burgwork> bddebian, don't feel bad. I had to ask several times what FTBFS meant about 18 months ago
[11:37] <infinity> Burgwork: What does FTBFS mean?
[11:39] <mdz> infinity: You're fired.
[11:39] <bddebian> Heh
[11:39] <infinity> Hard to resist.
[11:40] <Burgwork> anybody say thing?
[11:40] <tseng> Burgwork: nope.
[11:40] <tseng> Burgwork: but infinity was fired
[11:40] <bddebian> Burgwork: :)
[11:40] <bddebian> hah
[11:41] <Burgwork> damn. going to miss infinity 
[11:41] <infinity> Lies.
[11:41] <Burgwork> even if he is a traitor to his own country ;)
[11:41] <bddebian> FTBFS == Forgot To Bring Fricking Shot-glass?
[11:42] <infinity> FTBFS, loosely translated, is "That Which Keeps infinity Employed"
[11:42] <infinity> The reason the letters don't seem to match up is because it's translated from the original Latin.
[11:42] <bddebian> haha
[11:42] <azeem> what's infinity in latin?
[11:42] <LaserJock> Burgwork: you're actually using that stuff? ;-)
[11:42] <jdong|coreduo> lol
[11:43] <infinity> azeem: infinitum, but let's not split hairs.
[11:43] <jdong|coreduo> mvo: do you have anything to do with opera in dapper-commercial?
[11:43] <Burgwork> LaserJock, we dog food quite extensively. Mostly it is good, but occasionally we get all sorts of pain
[11:44] <bddebian> Hah
[11:45] <LaserJock> Burgwork: is DM more stable on FC than on dapper?
[11:45] <slomo> hm, what happened to the 2nd powerpc buildd?
[11:45] <mvo> jdong|coreduo: Mithrandir uploaded opera into dapper-commercial. why?
[11:46] <LaserJock> Apple pushed the self-destruct button?
[11:46] <Burgwork> LaserJock, it is mostly stable. We have a set hardware formula though.
[11:46] <Burgwork> radeon 7000
[11:46] <Burgwork> LaserJock, on my i915 box, it simply power cycles constantly
[11:47] <jdong|coreduo> mvo: users are requesting the 9.01 update
[11:48] <infinity> slomo: Weird grid failure in the DC, being investigated, current ETA unknown.
[11:50] <slomo> infinity: thanks... so i really have to wait for gcj to finish ;)
[11:50] <infinity> slomo: Yes. :P
[11:51] <jdong|coreduo> crimsun: is there any chance for azureus 2.5.0.0 from sid -> edgy?
[11:51] <jdong|coreduo> our ubuntu version is pretty unusable
[11:52] <bddebian> jdong|coreduo: It's on the merges list
[11:52] <jdong|coreduo> ok, cool
[11:52] <jdong|coreduo> nvm then
[11:52] <bddebian> I think I tried it once but it didn't build or something strange
[11:52] <jdong|coreduo> I wouldn't be surprised
[11:53] <slomo> bddebian: but nobody will probably touch it... it's not the easiest merge and the tarballs differ and doko did fairly large changes
[11:53] <bddebian> slomo: I tried :)
[11:54] <bddebian> Later folks
[11:54] <slomo> bddebian: me too but i gave up :P maybe doko cares for it at some point
[12:00] <geser> infinity: could you please giveback mail-notification and link-monitor-applet on sparc and powerpc?
[12:02] <infinity> geser: Done.
[12:02] <geser> thanks