[00:26] 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] slangasek: great thanks [00:27] slangasek: I'm writting my UDW session about server packages [00:27] slangasek: and plan a topic about upstart jobs [00:27] ah :) [00:27] slangasek: do you have specific ideas about upstart features useful for daemons? [00:28] slangasek: I already have: supervision [00:28] slangasek: support for forking daemons [00:28] slangasek: examples of running daemons in foreground [00:28] 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] mathiaz: automatically cascading restarts? [00:29] slangasek: oh nice [00:29] slangasek: examples? [00:29] (service portmap restart -> restarts portmap, gssd, statd) [00:30] not sure that's actually /needed/ for either of those services, but in practice it will happen :) [00:30] slangasek: is this already available in lucid? [00:30] yes [00:30] and in karmic [00:30] slangasek: do you have example of an upstart job that starts a process that forks [00:30] slangasek: IIRC there is the fork keyword available [00:30] slangasek: or expect fork - something like that [00:31] mathiaz: many do... ssh, portmap, atd, et al [00:31] 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] really? that's not a caveat Keybnz has mentioned :) [00:32] slangasek: any other ideas about Upstart feature relevant for managing daemons? [00:32] He has mentioned it repeatedly. [00:33] mathiaz: built in support for oom handling? [00:33] ion: to you, apparently, but not anywhere that I've picked up on it... [00:33] mathiaz: +nicing +limits [00:33] slangasek: hmmm - any examples of this use? [00:34] mathiaz: ssh in lucid; for the other two I don't have live examples, just init(5) [00:34] 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] ion: oh, fragile in that you have to tell upstart what to look for, sure [00:35] 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] slangasek: great - thanks for the input! [00:35] 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] slangasek: I also noticed that there wasn't a reload command [00:35] If the shell script does a fork-and-exec for an external command, the code will shit itself. :-) [00:36] slangasek: hm - sorry [00:36] slangasek: a force-reload command [00:36] The proper implementation in Upstart 0.10 or whatever it’ll be called will handle that, too. [00:36] slangasek: as mentionned in the Debian policy [00:37] mathiaz: Debian policy describes the behavior of init scripts in /etc/init.d; the upstart-job shim implements force-reload [00:38] (though I'm not sure the 'reload' command is the right backend for that, maybe we have a bug there) [00:38] slangasek: is there a way to specify in the upstart job the command to be used for reload? [00:38] slangasek: ie send SIGUSR2 to the process for example? [00:41] no [00:49] okay. can somebody tell me why reinstalling packages doesn't actually reinstall files? [00:49] if i reinstall the pulseaudio package after rm'ing the /etc/pulse directory, i expect it to be restored. [00:49] i shouldn't have to purge and then install [00:50] LLStarks: /etc/pulse/ contains conffiles (as defined by dpkg), and dpkg makes sure that your changes to conffiles are preserved across installs. [00:50] how do i override? [00:50] Well, you've found one way; purging will remove dpkg's memory of your conf file changes. [00:51] well, that can break and uninstall other packages [00:51] is there a more direct way? [00:52] dpkg --purge --force-depends should purge just the package you're interested in, leaving everything else installed (but broken). I think. [00:52] Then installing again will reconfigure everything. [00:53] IIRC there are some options to dpkg to force reinstall of missing /etc/ files [00:54] LLStarks: try "dpkg --force-confmiss $the.deb" [00:54] thanks. === TLUL is now known as TLUL_teh_lurker === TLUL_teh_lurker is now known as TLUL === joshua is now known as Guest57151 === v is now known as vorian === joshua is now known as Guest23314 === vish is now known as mac_v === mac_v is now known as vish [10:40] 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] persia: when is your slot? I haven't done any prep work yet [10:54] Friday [10:54] * persia digs up the exact time [10:55] 29th January 20:00 UTC. It's 5:00 saturday local for me, so I really won't miss it :) === arand_ is now known as arand [13:20] is it possible to create nfs shares without requiring root access? [13:20] if it was, then i could possibly expand nautilus-share's scope to include NFS support. === ryanakca_ is now known as ryanakca === Eren is now known as Guest34070 === Nafallo_ is now known as Nafallo === yofel_ is now known as yofel === andresmujica1 is now known as andresmujica === andresmujica1 is now known as andresmujica [19:34] what's the solution for the python and linking with ssl issue? [19:35] What's the issue? [19:37] I'm trying to merge vim and got the problem that linking with python failed because of -lssl not being there [19:38] I remember that some other builds had similar issues in the past too [19:53] 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] 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] 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] _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] _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] _Groo_: For kdebindings? [20:03] 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] _Groo_: For Lucid, it's in the Ubuntu archive. [20:04] <_Groo_> ScottK: link pls? [20:05] _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] What is the difference between Python packages in /usr/share/pyshared/ and those in /usr/share/? [21:35] Generally the ones in /usr/share/pyshared are designed to (properly) support more than one Python version on a system.