[04:50] <johnnybuoy> hey all!
[04:50] <Keybuk> hey
[04:50] <fdsd> hey guys, is there a howto on how to disable startup daemons, like gdm..
[04:52] <johnnybuoy> !upstart
[04:53] <Keybuk> fdsd: is gdm being run by upstart, or just by sysv-rc?
[04:53] <Keybuk> johnnybuoy: ?
[04:53] <fdsd> Keybuk, no idea
[04:54] <Keybuk> fdsd: which distro?
[04:54] <fdsd> Keybuk, i need to turn off everything not need to just boot to the shell
[04:54] <fdsd> edgy knot3
[04:54] <Keybuk> you can disable gdm by renaming the /etc/rc2.d/S13gdm symlink to /etc/rc2.d/K13gdm
[04:54] <fdsd> ok
[04:55] <fdsd> Keybuk, no easy thing like in gentoo rc-update del gdm default?
[04:56] <Keybuk> not in Ubuntu, no
[04:56] <fdsd> ok
[04:56] <Keybuk> (this has nothing to do with upstart, of course)
[04:56] <fdsd> usplash is a pain in the neck in edgy
[04:56] <fdsd> ugg
[04:57] <johnnybuoy> well, yeah...
[04:57] <johnnybuoy> it don't work, no?
[04:57] <thom> (you could use update-rc.d)
[04:57] <Keybuk> thom: except that always does exactly the wrong thing
[04:57] <Keybuk> and results in an upgrade restoring the symlinks
[04:58] <thom> right, because there's no way you can signal to make it persist without removing the init script
[04:59] <johnnybuoy> really?
[04:59] <johnnybuoy> hmm
[04:59] <johnnybuoy> that's no good...
[07:29] <kakalto> has upstart been tried under gentoo yet?
[07:29] <Keybuk> I believe someone has, yes
[07:30] <kakalto> succeedingly?
[07:32] <Keybuk> haven't heard
[07:32] <Keybuk> either way
[07:33] <kakalto> any ideas what it would require for me to attempt to work it?
[07:33] <Keybuk> usual, see the getting-started doc
[07:33] <kakalto> cool
[07:33] <kakalto> thanks
[08:59] -ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
[08:59] -ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
[09:15] <Steven_Shiau> anyone know how to switch the default runlevel to 1 or 3 or other than 2 when edgy alpha3 boots ?
[09:15] <Steven_Shiau> since now it's upstart, and /etc/inittab is no more.
[09:16] <Keybuk> edit /etc/event.d/rc-default
[09:16] <Keybuk> the default runlevel is 2
[09:16] <Keybuk> and 3 is identical to it
[09:17] <Keybuk> (assuming you have a fresh install, there's no particular reason you should bother with runlevels at all)
[09:17] <Steven_Shiau> Thanks. that's true, but sometimes I need special runlevel to do special thing
[09:18] <Keybuk> *nods*
[09:18] <Keybuk> so for fresh install, edit /etc/event.d/rc-default and change "telinit 2" to "telinit 3"
[09:19] <Keybuk> for upgrades, you will still have /etc/inittab and that will still be used
[09:19] <Steven_Shiau> thanks. The version I am using is:  upstart        0.2.7-1
[09:20] <Steven_Shiau> but I did not find /etc/inittab, so do you mean later version or ?
[09:20] <Keybuk> I mean upgrades from dapper
[09:20] <Keybuk> if you installed edgy fresh, you won't have an /etc/inittab because it's deprecated
[09:20] <Keybuk> but if you upgraded from dapper, /etc/inittab will still be there, and the default runlevel specified in that will still be used
[09:20] <Steven_Shiau> oh, ic. actually I did a fresh install.
[09:21] <Keybuk> you could also, in edgy, do "echo id:3:initdefault: > /etc/inittab
[09:21] <Steven_Shiau> got it. appreciate that
[09:21] <Steven_Shiau> so in the future, upstart will still respect the /etc/inittab ?
[09:21] <Keybuk> for edgy it will, yes
[09:22] <Keybuk> edgy+1 will not respect runlevels as much
[09:22] <Steven_Shiau> ic. tkx
[09:22] <Steven_Shiau> another question, how can I see more messages when my edgy box reboot or boots ?
[09:23] <Keybuk> take "quiet" off the kernel command line
[09:23] <Steven_Shiau> yes, I already did that.
[09:23] <Steven_Shiau> and no usplash at all
[09:23] <Steven_Shiau> but it seems that the messages are still less than before
[09:23] <Keybuk> you may need some updates due today
[09:23] <Steven_Shiau> for upstart 0.2.7-2 ?
[09:24] <Keybuk> upstart, lsb-base and sysvinit will all need updating
[09:24] <Steven_Shiau> got it.
[09:25] <Steven_Shiau> my last question
[09:25] <Keybuk> shoot
[09:26] <Steven_Shiau> I need to run a script (/etc/rc2.d/S99firstboot) when edgy boots so that people can enter some number to choose some config, etc. It works in dapper. However, now with edgy alpha3, I can not do it.
[09:27] <Steven_Shiau> since all the service just run, and won't wait for me to enter
[09:27] <Steven_Shiau> Is that possible to do that ?
[09:30] <Keybuk> yes
[09:30] <Keybuk> exec </dev/console >/dev/console 2>&1  at the top of the script
[09:30] <Steven_Shiau> in my S99firstboot ?
[09:30] <Keybuk> yes
[09:31] <Steven_Shiau> great!
[09:31] <Steven_Shiau> That finishes all my questions. Appreciate that.
[09:31] <Keybuk> alternately write the firstboot as an upstart job (/etc/event.d/firstboot) run when the rc script finishes (start on rc3/stop) and on the console (console output)
[09:32] <Steven_Shiau> excellent!
[09:32] <Steven_Shiau> that's the benefit of upstart!
[09:33] <Keybuk> well, at the moment we're just using it to replace sysvinit and not do anything extra
[09:33] <Keybuk> to prove the daemon works
[09:34] <Steven_Shiau> But it will be better in the future
[09:34] <Steven_Shiau> definitely
[11:32] <Seveas> Keybuk, there was an impromptu lightning talk session here at EuroOscon - I pimped upstart, hope you don't mind 
[11:32] <Seveas> people were impressed by it
[05:28] <Keybuk> has anyone had much experience with gtk-doc-tools, linuxdoc-tools, or doxygen, etc.?
[05:29] <Keybuk> how do you find it to use?
[05:30] <LarstiQ> rather ok, though more burdensome than epydoc with docstrings.
[05:31] <Keybuk> epydoc is a python thing?
[05:32] <LarstiQ> yes.
[05:34] <mbiebl> Keybuk: Since you use binary:Version now in debian/control, you should add a versioned build-dep on dpkg-dev (>= 1.13.19)
[05:34] <_ion> doxygen is quite nice.
[05:35] <Keybuk> mbiebl: could you file a bug for me?
[05:36] <mbiebl> Will do
[05:37] <Keybuk> on the ubuntu source, obviously
[05:39] <mbiebl> sure ;-)
[05:45] <mbiebl> #61693
[05:45] <Keybuk> thanks
[05:45] <Keybuk> hope to start moving towards 0.5 this weekend
[05:46] <_ion> Cool.
[05:46] <mbiebl> What features are planned for 0.5?
[05:46] <Keybuk> https://wiki.ubuntu.com/UpstartDesignChanges
[05:47] <_ion> (topic)
[05:48] <mbiebl> We should probably put out some more sophisticated examples then.
[05:48] <mbiebl> So that people get a feeling how to write upstart jobs.
[05:48] <Keybuk> how do you mean?
[05:48] <Keybuk> once 0.5 is out?
[05:49] <mbiebl> Yes, explaining, which features/keywords already work e.g.
[05:49] <Keybuk> yes, I agree
[06:28] <wasabi__> The hardest part of those changes I think will be faking a call stack
[06:28] <wasabi__> for event blocking
[06:28] <Keybuk> event blocking?
[06:28] <wasabi__> Well, if an event can fail, then it must return a failure status.
[06:29] <wasabi__> And to do that, it must document which jobs were effected by it
[06:29] <wasabi__> And those jobs themselves can emit events that invoke other jobs.
[06:29] <wasabi__> Meaning they themselves wait for the results of those events;.
[06:30] <Keybuk> that's the question, do we want to wait for resulting events, or just jobs?
[06:30] <wasabi__> Well, before the results of an event can be known, all the jobs must complete.
[06:30] <Keybuk> define "complete"
[06:31] <wasabi__> transition to the stage that the emitted event caused them to set as a goal
[06:31] <wasabi__> or fail.
[06:31] <Keybuk> right, so that doesn't require event chaining
[06:31] <Keybuk> e.g. if that job emits an event, then that's not part of the goal or "complete"-ness
[06:31] <wasabi__> If I emit do-some-stuff, whcih causes a job to move from stop to start, do-some-stuff's result cannot be known until that job has finished entered started.
[06:31] <wasabi__> During which, it might have issued it's own events, which it itself is waiting on.
[06:31] <Keybuk> yes, that's true
[06:32] <wasabi__> So, it's a pretend call stack, managed with a main loop.
[06:32] <Keybuk> except you don't actually need the call stack
[06:32] <wasabi__> Yeah. Never said you did. It just behaves as one.
[06:32] <wasabi__> Which is interesting from an academic POV. :0
[06:32] <Keybuk> the job is waiting on an event inside a process
[06:33] <wasabi__> Well, for instance, if a job transitions from STOPPED to STARTING, upstart itself emits job-name starting
[06:33] <wasabi__> The results of which could fail.
[06:33] <wasabi__> And should prevent the job from continuing.
[06:33] <Keybuk> should it, why?
[06:34] <Keybuk> I don't think it should
[06:34] <wasabi__> Really?
[06:34] <wasabi__> Because being able to write a new job that effects the startup process of another job, is interesting.
[06:34] <Keybuk> yes, but it's possible by just adding "stop on event-failed job-started job-name" :)
[06:34] <wasabi__> Lets you modify the first job without changing its file, resulting in easier management (upgrades to the job's package don't need to deal with changes to the job file)
[06:34] <wasabi__> Hmm.
[06:34] <pepsiman> wasabi__: the word is "affects"
[06:35] <wasabi__> Heh.
[06:35] <wasabi__> I'd prefer to make it as unneccassary as possible for an admin who desires to attach conditionals to a job installed by a package, to edit that jobs file himself. Not required, but it seems a worthy goal.
[06:36] <wasabi__> Easies package upgrades.
[06:36] <Keybuk> but then you have strange problems
[06:36] <wasabi__> Well, upstart has or will have an api like thus:
[06:36] <Keybuk> where the author of some job never expects anything to handle its events
[06:36] <Keybuk> and something does
[06:36] <wasabi__> evt = event_new("job-starting", job.name); wait for evt to exit
[06:37] <wasabi__> Well. That's true.
[06:37] <wasabi__> I suspect though the interference on the original job would be small, since you'd only be able to attach to built in events.
[06:38] <wasabi__> And those would only be able to return success/fail, to abort or continue.  Nothing that can modify the original job's state in any breaking way.
[06:39] <Keybuk> I just don't think that a job should be affected by other jobs unless it wants to be
[06:44] <Keybuk> the worst example I can think of is mount-filesystem ;)
[06:44] <wasabi__> Heh.
[06:44] <Keybuk> you'd end up failing the entire system if a singel job that reacted to that event failed :p
[06:45] <wasabi__> Oooh.
[06:45] <wasabi__> Good point.
[06:46] <Keybuk> anyway, gonna go to sleep :)  been up for 30H or so
[06:46] <Keybuk> nite
[06:46] <wasabi__> wow nite
[08:35] <johnnybuoy> hello!
[08:35] <johnnybuoy> can I get help for upstart in edgy here?
[08:37] <LarstiQ> what help would that be?
[08:38] <johnnybuoy> can I get ttys working, or is this a known bug?
[08:39] <LarstiQ> it sounds familiar, let me see if I can find anything
[08:40] <johnnybuoy> /etc/default/console-properties is set properly, i think
[08:41] <LarstiQ> johnnybuoy: my ttys seem to be working fine in edgy fwiw, and I don't see anything relevant in my backlog
[08:41] <johnnybuoy> hmmm
[08:41] <johnnybuoy> many ppl in ubuntu+1 have this prob.
[08:41] <LarstiQ> johnnybuoy: you have  startup-tasks and system-services installed?
[08:42] <johnnybuoy> LarstiQ, and no messages when booting without usplash
[08:42] <johnnybuoy> hmm
[08:42] <johnnybuoy> nope.
[08:42] <johnnybuoy> is it not a dep?
[08:42] <LarstiQ> johnnybuoy: I think the messages would be  upstart-logd\
[08:42] <LarstiQ> johnnybuoy: a Recommends
[08:42] <LarstiQ> johnnybuoy: could you try that and report if it works?
[08:44] <johnnybuoy> LarstiQ, upstart-logd is installed
[08:44] <johnnybuoy> LarstiQ, ok
[08:45] <johnnybuoy> what if my pc doesn't boot?
[08:45] <johnnybuoy> hmm?
[08:45] <LarstiQ> I doubt that will happen
[08:45] <johnnybuoy> I have those packages
[08:45] <johnnybuoy> both
[08:46] <johnnybuoy> all three ;)
[08:46] <LarstiQ> I'm out of ideas then
[08:46] <johnnybuoy> hmm
[08:46] <johnnybuoy> :(
[08:46] <johnnybuoy> it's scary, cause what if X fails me?
[08:46] <johnnybuoy> i don't even know how to control upstart :(
[08:47] <johnnybuoy> does it have anything to do with
[08:47] <johnnybuoy> /etc/event.d/tty* files?
[08:48] <LarstiQ> you could install sysvinit for the time being, if that makes you feel safer
[08:48] <johnnybuoy> cat /var/log/messages |grep tty gives me only one tty...
[08:49] <johnnybuoy> ttyS1
[08:49] <johnnybuoy> what is LSR safety check?
[08:51] <LarstiQ> johnnybuoy: see /var/log/boot
[08:51] <LarstiQ> johnnybuoy: what I've personally also done is remove quiet and splash from the kernel arguments
[08:53] <johnnybuoy> LarstiQ, I tried that, but now splash works fine, do you think that splash is responsible for me not having ttys?
[08:53] <LarstiQ> johnnybuoy: it does do nasty things with your console, yes
[08:54] <johnnybuoy> hmm
[08:54] <johnnybuoy> ok
[08:54] <johnnybuoy> I'll try with splash disabled
[08:55] <johnnybuoy> brb
[09:01] <johnnybuoy> hmm :)
[09:01] <johnnybuoy> usplash *does* do strange things with the console :(
[09:05] <mjg59> What sort of strange things, and what kernel arguments are you using?
[09:06] <johnnybuoy> vga=791 splash = silent and quiet are the relevant kernel arguments, I guess
[09:07] <mjg59> Lose vga=
[09:07] <johnnybuoy> really?
[09:07] <mjg59> Yes
[09:07] <johnnybuoy> ok, brb :)
[09:14] <johnnybuoy> whoyesss!!!
[09:15] <johnnybuoy> thanks! removing vga=* kernel param I get usplash and tty...
[09:15] <johnnybuoy> :)
[09:15] <johnnybuoy> THX
[09:59] <dippie> hello
[11:32] -ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
[11:32] -ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
[11:37] !christel:*! Hi all, we just had a minor connectivity issue with one of our servers. Affected users: ~3000. All should be back to normal. Have a great day!
[12:19] !alindeman:*! Hi all!  You may notice some bots around the net attempting to exploit a bug in some routers (whereby they crash on a malformed DCC SEND string).  We're doing our best to mitigate the visibility of these bots, but if you're still being affected (i.e., disconnected) by them, please consider upgrading your router firmware ( http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1068 ) and/or connecting to freenode on a non-IRC port, such as 8001.  Thanks!  I