[12:16] jodh: (Moving here, as it's not really on topic for #launchpad) So what are the current requirements for (current) upstart? [12:20] soren: wrt the kernel version '2.6.24' according to Keybuks top-level README. The PPA environment appears to provide 2.6.24-32-xen. Upstart is built and run in many other environments and we've never seen the test failures currently seen when attempting to build lp:upstart in a PPA env. [12:21] soren: so that kernel version _may_ be problematic although I do not understand how the kernel version could cause the failure we're seeing. [12:21] jodh: Do older versions fail in the same way? Did the environment change? [12:23] soren: older versions of what? We have never been able to build lp:upstart in a PPA env sadly, due to the issue outlined. [12:24] jodh: Oh, I thought it was a new issue. [12:24] jodh: Wow, so upstart has never built in PPA's? Ever? [12:26] https://launchpadlibrarian.net/124769395/buildlog_ubuntu-quantal-amd64.upstart_1.5-0ubuntu9_BUILDING.txt.gz [12:30] soren: correct - I was the first to try it I believe some months back and have been trying to work out what the problem is. [12:31] soren: no - not the ubuntu build, the build of lp:upstart. [12:33] soren: it does build, but cannot run/pass upstream test-suite. But the reason why we want to build in the ppa is to have daily-builds and test-suite runs. [12:36] xnox: Doesn't the Ubuntu build run the test suite? [12:37] soren: it does, but not on every upstream commit & we are doing a lot of upstream development this cycle. [12:40] xnox: I don't follow. So the upstream test suite is run by the Ubuntu builds and these Ubuntu builds work in PPA's, but not "upstream" builds. Am I correct so far? [12:41] soren: not quite. [12:42] soren: lp:ubuntu/upstart is quite modified from lp:upstart. When we merge lp:upstart into lp:ubuntu/upstart and upload into the ubuntu archive, non-virt distro builders build it / ran the test-suite and all is fine. [12:43] soren: but when we upload just lp:upstart into the ppa (without ubuntu specific modifications) it builds, but the test-suite hangs the virt PPA. [12:43] * xnox is now not sure if that's what you meant or not. [12:44] I think so. [12:46] I'm just a wee bit surprised that we have one version that works and another that doesn't (which is a pretty good starting point for pinpointing the problem if it can't be done by simple code inspection), yet instead of fixing the problem we're replacing the build infrastructure to avoid it. [12:48] Not my call, obviously, but I'm just concerned that the issue causing this failure is going to come bite me in the behind one day. [13:27] soren: We are surprised too [13:28] soren: is there any plan to upgrade the PPA env environment to atleast lucid? [13:28] jodh: I have no idea. [13:28] * soren is not involved with Launchpad [13:28] Sorry if I gave that impression. [13:33] soren: ok. so back to #launchpad? :-) [13:53] jodh: I am looking at the multiple directories support and upstart does cleanly support multiple conf sources, but the libnih option parsing just uses the last one passed. [13:54] jodh: so the question I have, is do we want syntax similar to: [13:54] --configdir dir1 --configdir dir2 [13:54] or [13:54] --configdir dir1:dir2 [13:55] in the first-case libnih should get support for building up a nih_list of options, in the latter case proper : splitting and escaping validation needs to be done. [13:56] it is a bit moot, since --user (or whatever option we will use for user sessions) will default to a list of xdg-config environment variables with fallbacks. [13:56] fallbacks to default xdg locations.... [13:59] xnox: I'd prefer '--confdir dir1 --confdir dir2' [13:59] jodh: ack. [14:00] jodh: i will look into tricking libnih to build a nih_list from those. [14:00] xnox: this is possible with nih by utilising an NihOptionSetter. See ignored_events_setter() in initctl.c for an example. [14:00] xnox: nih will 'visit' each argument, and call the provided setter function each time. [14:00] jodh: should it be --configdirs dir1 --configdirs dir2, cause currently --configdir dir1 --configdir dir2 results in dir2 being used by upstart. [14:00] xnox: so all you need to do is create a NihListEntry list and add the paths to it. [14:01] jodh: interesting. Let me look that up. [14:01] xnox: it should be '--confdir' as that is the current option name. [14:01] ok. [14:01] xnox: so yes, in the simplistic case, "the last option wins", but if you use a setter function, you have full control. === marrusl_ is now known as marrusl [14:02] jodh: it's just feel uneasy changing the meaning of current command line arg parsing. [14:03] s/feel/feels/ [14:03] hence the argument to support both --confdir & --confdirs. [14:03] but that can be confusing. [14:03] xnox: we're not changing the current behaviour though: '--confdir /foo/bar' should still continue to work. [14:05] jodh: '--confdir /foo/bar --confdir /bar/foo' today vs in future is changing, unless we reverse the confsource list (e.g. the last one has highest priority, i.e. first in the confsource list) [14:05] that should work. [14:09] xnox: well from the Upstart perspective nobody should be even using --confdir let alone specifying it multiple times :-) We could always add in a --traditional flag maybe but I'm not convinced its worth it. [14:10] xnox: what we could do is only use the new behaviour if --user is specified and document clearly in init(8) the impact using --user has on --confdir. [14:10] jodh: well we should have been erroring out on passing multiple confdirs, but we cannot turn the time back. [14:11] jodh: the "backwards" compatible way is to then list --confdir /etc/xdg/upstart --confdir /etc/xdg/xdg-ubuntu/upstart --confdir ~/.config/upstart [14:11] xnox: that's not how nih works by default. To do that, every option would need to have a setter which just shouldn't be necessary. [14:12] this way it looks good to me ( the ignorant) LTR speaker. [14:12] xnox: you forgot ~/.init :) [14:13] jodh: the impact difference is that in the past only the jobs in the last confdir were used, but now the unique onces in the previous dirs will also be used. [14:13] jodh: but that does not help with the environment variable. [14:14] jodh: what priority UPSTART_CONFDIR has? =) [14:14] and XDG_CONFIG_HOME? =) [14:20] xnox: we have (attempted to) document this behaviour here: https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Configuration_Files_for_User_Jobs [14:21] xnox: although I've never heard of UPSTART_CONFDIR :) [14:22] * CONFDIR_ENV: [14:22] * [14:22] * If this environment variable is set, read configuration files [14:22] * from the location specified, rather than CONFDIR. [14:22] * [14:22] * Value is expected to be the full path to an alternative job [14:22] * configuration directory. [14:22] **/ [14:22] #ifndef CONFDIR_ENV [14:22] #define CONFDIR_ENV "UPSTART_CONFDIR" [14:22] #endif [14:22] =)))))))))))))))))))))))))))))) [14:22] jodh: blame says 1284.1.1 james.h =))))) [14:25] xnox: that was added for testing and is not a documented "external". [14:27] jodh: shows up in the gtk-docs I generated locally ;-) [14:27] jodh: what does CONFFILE "/etc/init.conf" used for? [14:28] is it in the case when upstart is used as sysvinit compat mode only? and /etc/init.conf bootstraps that and that's it [14:28] ? [14:31] jodh: Well, what I wanted to discuss was about upstart, not Launchpad. Hence the move here. But meh. [14:31] xnox: init.conf is not used at all right now. [14:32] jodh: sure, but it's loaded as a conf source by default =) [14:32] xnox: ignore it. [14:32] =)))) [15:13] jodh: "Currently, PID 1 looks for a users Job configuration files in directory $HOME/.init/. This behaviour will be retained." [15:14] as in the PID 1 will continue to parse those, or will the usersession upstart parse those at the highest priority? [15:17] jodh: and the override file will only "work" next to the job file. [15:18] e.g. ~/.config/upstart/foo.override will not override /etc/xdg/upstart/foo.conf, but /etc/xdg/upstart/foo.override will override /etc/xdg/upstart/foo.conf [15:20] xnox: that sentence is certainly ambiguous. Certainly only the Session Inits should be considering ~/.init for enhanced sessions. I think we should document ~/.init as deprecated, but honour it for now as being the first directory to search. [15:22] xnox: well, we want the user to be able to disable a system job, so ~/.config/upstart/foo.override should override /etc/xdg/upstart/foo.conf. I think it would be highly beneficial if you added some more detail to the spec on this to make it totally clear. We can discuss tomorrow if you like with stgraber? (currently trying to get something finished by COB :) [15:22] So the order is: --confdir ; ~/.init ; xdg_config_home; for each in xdg_config_dirs [15:22] first one wins. [15:23] jodh: no. I disagree, because ~/.config/upstart/foo.conf will be treated higher priority than /etc/xdg/upstart/foo.conf [15:23] jodh: but the system administrator may want to override that job for all users in /etc/xdg/upstart/foo.override [15:24] xnox: yes. ok, well lets add some more use cases to the spec and discuss tomorrow? [15:24] jodh: and the user may want to temprorarly over-override ~/.config/upstart/foo.conf with ~/.config/upstart/foo.override, regardless whether /etc/xdg/upstart/foo.* exist or not.