[12:40] <sadlede1> mbiebl: hi, how are you planning to integrate replacement-initscripts into debian when they get used in ubuntu?
[12:40] <mbiebl> sure, I'm already working on them ;-)
[12:41] <mbiebl> sorry, but I have to run now...
[12:41] <mbiebl> cu later
[01:45] <fatal> about interaction with user.... why would anyone want to do that during boot?
[01:45] <Keybuk> retrieving keys for encrypted filesystems
[01:45] <Keybuk> (or Apache SSL passphrases)
[01:45] <Keybuk> driving fsck responses
[01:46] <fatal> why not provide that on the boot command line?
[01:46] <fatal> I wouldn't want my bootup to halt on some stupid question...
[01:47] <fatal> guess you could define some base services that shouldn't ask any question to get around that though.
[01:50] <Keybuk> some people do want their boot to halt though
[01:50] <Keybuk> though heres a thought ... pre-seeding answers to questions ;p
[01:50] <_ion> "Yo Linux! If something in the boot asks whether i want to fix inode 46837, the answer is yes."
[01:51] <Keybuk> or "just fix every damned fsck thing"
[01:51] <Keybuk> (who doesn't hold down the "Y" key until fsck goes away? :p)
[01:51] <Keybuk> "no, actually, I don't want to fix my filesystem)
[01:51] <_ion> I *always* set FSCKFIX=yes
[01:52] <_ion> If we were evil enough, we could use libwhat to let the user input her login and password before gdm is started. :-)
[01:56] <fatal> seems like you're on the same track as me.... you don't want questions during bootup. ;P
[01:56] <fatal> "just do the right thing"<tm> :)
[02:03] <fatal> encrypted partitions might be a separate issue.... still I'd rather have the answer provided from the start and no questions asked... (or extend grub to ask questions if something more "user friendly" is needed. I guess grub could even be smart about it... grub reads filesystems already, no? Could check /etc/fstab on the fly if any key is needed... or if the root partition needs would know that as well when trying to access it?)
[02:04] <fatal> not sure about apache / ssl-keys ... why would you want to auto-start something that can't be auto-started?
[02:08] <sadlede1> _ion: or just start gdm on a framebuffer ;-)
[02:14] <Keybuk> gdm takes ages to start
[02:18] <sadlede1> Keybuk: sure, just kidding
[02:24] <pkt_> well, qingy is a framebuffer getty and it is themeable and whatnot
[02:25] <pkt_> if you want a framebuffer screen for logging in this is much better than nihing your own
[03:25] <_ion> fatal: If i were using an encrypted partition or apache with a password-protected SSL key, i'd definitely want to be queried for the passwords.
[03:29] <_ion> keybuk: Btw, any new progress with the delayed watch stuff?
[03:29] <Keybuk> _ion: none, I have a half merge in my working branch
[03:29] <Keybuk> it's been a busy week
[03:30] <Keybuk> lots of CVs to read :-/
[03:30] <_ion> Alright.
[03:36] <sadlede1> mbiebl: i found your upstart-jobs branch
[03:37] <mbiebl> hehe, that's not yet ready for public use though.
[03:37] <sadlede1> mbiebl: how are you going to push that into debian? will the jobs be in the indiviual packages?
[03:37] <mbiebl> That's my long term goal, yes.
[03:38] <sadlede1> mbiebl: sure, i'm just curious how the process will be
[03:40] <mbiebl> Short term, I will ship the upstart jobs for the most important packages myself.
[03:40] <mbiebl> Upon installation of the upstart-jobs package, I will scan which packages are currently installed, deactivate the sysv init script and activate the corresponding upstart job.
[03:40] <mbiebl> If I have a working set of native upstart jobs, I will start to ping the individual package maintainers and ask for them to include these files directly.
[03:40] <mbiebl> As I'm (co)-maintainer of dbus/hal/dhcdbd/network-manager I can do that for these packages directly.
[03:41] <mbiebl> (avahi-daemon too)
[03:45] <sadlede1> ok, so packages will provide both a sysv script and an upstart job
[03:51] <sadlede1> mbiebl: so i'm very much looking forward to using the first round of debian upstart-jobs
[03:51] <mbiebl> If you're willing to test them and give me feedback, that would be great.
[03:52] <sadlede1> do you run the jobs from upstart-jobs?
[03:52] <mbiebl> Maybe I have something working around mid next week.
[03:53] <mbiebl> http://pastebin.ca/406556
[03:54] <mbiebl> So, basically the rc2.d/multiuser part is upstartified already.
[03:56] <sadlede1> wow!
[03:56] <sadlede1> btw, shouldn't avahi-daemon do the .local check from the sysvrc script?
[03:56] <sadlede1> policykit is not yet in debian, is it?
[03:57] <mbiebl> I'm currently packaging it for experimental while preparting hal-0.5.9 packages.
[03:57] <mbiebl> Its in the pkg-utopia svn
[04:02] <mbiebl> Something to wet your appetite:
[04:02] <mbiebl> http://debs.michaelbiebl.de/upstart/bootchart.png
[04:06] <sadlede1> oh dear!
[04:11] <mbiebl> around 15 sec the fully upstartified boot process kicks in.
[04:11] <sadlede1> oh yes, that point isn't hard to find ;-)
[04:11] <mbiebl> cu later
[04:11] <sadlede1> and the first part will be fast as well
[04:11] <sadlede1> ok, cu
[04:45] <tale_> can upstart detect docking events?
[05:03] <Keybuk> tale_: was just about to reply to your e-mail ... :)
[05:03] <Keybuk> Upstart doesn't detect anything itself, it relies on things like udev, HAL, GNOME Power Manager, etc. to do all of the detection and handling
[05:03] <Keybuk> those processes request an upstart event be emitted through libupstart or the "initctl emit" tool
[05:03] <Keybuk> so provided you've got something already that can detect a docking event, it's just a matter of making it send an event to upstart
[05:03] <Keybuk> at which point upstart will start and stop services
[05:03] <Keybuk> the only events that upstart emits itself are "startup" and those due to jobs changing states
[05:03] <tale_> Keybuk, yeah I didn't notice the irc group until I had sent that email.
[05:04] <tale_> Keybuk, I'll do some more investigating to see how it is detected.   I know it can be detected because there is a script that can be setup, but from what I hear it's not trival.  This should work out of the box.
[06:20] <AlexExtreme> mbiebl, could you point me to your upstart jobs for debian sometime, i'd like to see what you're using there
[06:21] <AlexExtreme> brb, dinner
[06:21] <mbiebl> AlexExtreme: They are not ready yet. 
[06:21] <AlexExtreme> i know, but what you have so far
[06:22] <mbiebl> Give me some more time until I feel confident to announce them.
[06:42] <AlexExtreme> Ok
[07:26] <cortana> mbiebl: thanks for uploading a new tracker with my patch :)
[07:27] <mbiebl> You're welcome. I have to thank for the patch.
[07:48] <AlexExtreme> nice
[07:48] <AlexExtreme> syslog-ng doesn't write it's pid file when run with --foreground
[08:07] <mbiebl> AlexExtreme: Yeah, I used that too ;-)
[08:07] <AlexExtreme> :p
[08:08] <AlexExtreme> it was useful for my syslog-ng logrotate thing, but i'm writing a initctl pid command to replace that
[08:09] <mbiebl> argh, now I understood you.
[08:12] <mbiebl> AlexExtreme: what do you need the pid for?
[08:12] <AlexExtreme>         postrotate
[08:12] <AlexExtreme>                 /bin/kill -HUP `cat /var/run/syslog-ng.pid 2>/dev/null`  2> /dev/null || true
[08:12] <AlexExtreme>         endscript
[08:12] <AlexExtreme> that was what I had in the logrotate file for syslog-ng
[08:12] <mbiebl> That should imo be solved by providing a reload command 
[08:12] <mbiebl> within upstart
[08:12] <AlexExtreme> h,,
[08:12] <AlexExtreme> *hmm
[08:12] <AlexExtreme> true
[08:12] <AlexExtreme> i'll file a bug report
[08:12] <mbiebl> Yes, please.
[08:13] <mbiebl> reload should probably use SIGHUP as default.
[08:14] <mbiebl> But there also should be the posssibilty to define a separate signal for reload
[08:15] <mbiebl> e.g. some daemons also use SIGUSR1
[08:15] <AlexExtreme> ues
[08:15] <AlexExtreme> *yes