[00:26] <slangasek> mathiaz: for new stuff, definitely preferred to modify the job directly; for existing stuff, I've tried to respect the existing configs when converting
[00:27] <mathiaz> slangasek: great thanks
[00:27] <mathiaz> slangasek: I'm writting my UDW session about server packages
[00:27] <mathiaz> slangasek: and plan a topic about upstart jobs
[00:27] <slangasek> ah :)
[00:27] <mathiaz> slangasek: do you have specific ideas about upstart features useful for daemons?
[00:28] <mathiaz> slangasek: I already have: supervision
[00:28] <mathiaz> slangasek: support for forking daemons
[00:28] <mathiaz> slangasek: examples of running daemons in foreground
[00:28] <slangasek> I was intending to put together a talk about authoring upstart jobs for UDW, but I didn't see a call for sessions this time around (just an announcement of when it was that implied the slots were already filled)
[00:28] <slangasek> mathiaz: automatically cascading restarts?
[00:29] <mathiaz> slangasek: oh nice
[00:29] <mathiaz> slangasek: examples?
[00:29] <slangasek> (service portmap restart -> restarts portmap, gssd, statd)
[00:30] <slangasek> not sure that's actually /needed/ for either of those services, but in practice it will happen :)
[00:30] <mathiaz> slangasek: is this already available in lucid?
[00:30] <slangasek> yes
[00:30] <slangasek> and in karmic
[00:30] <mathiaz> slangasek: do you have example of an upstart job that starts a process that forks
[00:30] <mathiaz> slangasek: IIRC there is the fork keyword available
[00:30] <mathiaz> slangasek: or expect fork - something like that
[00:31] <slangasek> mathiaz: many do... ssh, portmap, atd, et al
[00:31] <ion> Upstart’s fork-following code is quite fragile currently. The next-gen Upstart will have a proper implementation that should handle any situation well.
[00:31] <slangasek> really?  that's not a caveat Keybnz has mentioned :)
[00:32] <mathiaz> slangasek: any other ideas about Upstart feature relevant for managing daemons?
[00:32] <ion> He has mentioned it repeatedly.
[00:33] <slangasek> mathiaz: built in support for oom handling?
[00:33] <slangasek> ion: to you, apparently, but not anywhere that I've picked up on it...
[00:33] <slangasek> mathiaz: +nicing +limits
[00:33] <mathiaz> slangasek: hmmm - any examples of this use?
[00:34] <slangasek> mathiaz: ssh in lucid; for the other two I don't have live examples, just init(5)
[00:34] <ion> If the job’s main command consistently does a fork or a double fork and you tell Upstart about it with the expect stanza, things will work.
[00:35] <slangasek> ion: oh, fragile in that you have to tell upstart what to look for, sure
[00:35] <ion> If the main command is a shell script that runs stuff and then execs the main daemon *that forks*, that’s likely to break the current implementation.
[00:35] <mathiaz> slangasek: great - thanks for the input!
[00:35] <slangasek> ion: right, that was one of the points for my theoretical UDW talk, under the heading "how to write an upstart job that you have to reboot to fix" :)
[00:35] <mathiaz> slangasek: I also noticed that there wasn't a reload command
[00:35] <ion> If the shell script does a fork-and-exec for an external command, the code will shit itself. :-)
[00:36] <mathiaz> slangasek: hm - sorry
[00:36] <mathiaz> slangasek: a force-reload command
[00:36] <ion> The proper implementation in Upstart 0.10 or whatever it’ll be called will handle that, too.
[00:36] <mathiaz> slangasek: as mentionned in the Debian policy
[00:37] <slangasek> mathiaz: Debian policy describes the behavior of init scripts in /etc/init.d; the upstart-job shim implements force-reload
[00:38] <slangasek> (though I'm not sure the 'reload' command is the right backend for that, maybe we have a bug there)
[00:38] <mathiaz> slangasek: is there a way to specify in the upstart job the command to be used for reload?
[00:38] <mathiaz> slangasek: ie send SIGUSR2 to the process for example?
[00:41] <slangasek> no
[00:49] <LLStarks> okay. can somebody tell me why reinstalling packages doesn't actually reinstall files?
[00:49] <LLStarks> if i reinstall the pulseaudio package after rm'ing the /etc/pulse directory, i expect it to be restored.
[00:49] <LLStarks> i shouldn't have to purge and then install
[00:50] <RAOF> LLStarks: /etc/pulse/ contains conffiles (as defined by dpkg), and dpkg makes sure that your changes to conffiles are preserved across installs.
[00:50] <LLStarks> how do i override?
[00:50] <RAOF> Well, you've found one way; purging will remove dpkg's memory of your conf file changes.
[00:51] <LLStarks> well, that can break and uninstall other packages
[00:51] <LLStarks> is there a more direct way?
[00:52] <RAOF> dpkg --purge --force-depends should purge just the package you're interested in, leaving everything else installed (but broken).  I think.
[00:52] <RAOF> Then installing again will reconfigure everything.
[00:53] <geser> IIRC there are some options to dpkg to force reinstall of missing /etc/ files
[00:54] <geser> LLStarks: try "dpkg --force-confmiss $the.deb"
[00:54] <LLStarks> thanks.
[10:40] <persia> slangasek: IF you're still interested in a UDW slot, you can have mine, as I'm just reprising a talk I've given lots of times (and I suspect all would be better served by a good understanding of upstart vs. me blathering about stacktraces again)
[10:51] <slangasek> persia: when is your slot?  I haven't done any prep work yet
[10:54] <persia> Friday
[10:54]  * persia digs up the exact time
[10:55] <persia> 29th January 20:00 UTC.  It's 5:00 saturday local for me, so I really won't miss it :)
[13:20] <hyperair> is it possible to create nfs shares without requiring root access?
[13:20] <hyperair> if it was, then i could possibly expand nautilus-share's scope to include NFS support.
[19:34] <geser> what's the solution for the python and linking with ssl issue?
[19:35] <ScottK> What's the issue?
[19:37] <geser> I'm trying to merge vim and got the problem that linking with python failed because of -lssl not being there
[19:38] <geser> I remember that some other builds had similar issues in the past too
[19:53] <geser> ScottK: looks like vim pulls in the value from LOCALMODLIBS from /usr/lib/python2.6/config/Makefile and -lssl is listed there
[19:55] <_Groo_> hi/2 all
[19:55] <ScottK> geser: Oh.  No idea on that one.
[19:56] <_Groo_> you guys are updating to rc2 as i can see, gonna have to update my kde multimedia pulseaudio as soon as you upload the new multimedia to lucid
[19:58] <ion> hi/2 looks like an Erlang function reference.
[19:59] <_Groo_> ion: actually its an os/2 old warrior reference
[20:00] <_Groo_> ScottK: is rc2 be up 100% today (also with kdebindings for the first time? oO
[20:01] <ScottK> _Groo_: I know it's building now.  I didn't help with the packaging this time around, so I don't know about kdebindings.
[20:01]  * _Groo_ cross is fingers
[20:02] <_Groo_> ScottK: but the complete package will be uploaded today?
[20:02] <ScottK> _Groo_: It's all uploaded now.  In the process of building.
[20:02] <_Groo_> ScottK: sorry i mean published :) do you have a url i could see fo check for building progress?
[20:03] <ScottK> _Groo_: For kdebindings?
[20:03] <ScottK> There isn't one url for all of KDE.
[20:03] <_Groo_> ScottK: no, i mean, are you using a ppa to test or something like that? i wanna check what packages are built and published already
[20:04] <ScottK> _Groo_: For Lucid, it's in the Ubuntu archive.
[20:04] <_Groo_> ScottK: link pls?
[20:05] <ScottK> _Groo_: There isn't one for all of KDE.  You should probably ask in #kubuntu-devel for someone who was involved in packaging it.
[20:07] <_Groo_> ScottK: OMG i forgot that konversation removed that tab lol.. you are right
[21:02] <qense> What is the difference between Python packages in /usr/share/pyshared/ and those in /usr/share/?
[21:35] <ScottK> Generally the ones in /usr/share/pyshared are designed to (properly) support more than one Python version on a system.