El Tue, 1 de Apr 2014 a las 4:05 AM, Dimitri John Ledkov <xnox@debian.org> escribió:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">On 26 March 2014 10:46, Simon McVittie <smcv@debian.org> wrote:
<blockquote> On Tue, 25 Mar 2014 at 22:41:32 -0007, Cameron Norman wrote:</blockquote><blockquote><blockquote> Please consider this for inclusion
</blockquote>
 Given that Ubuntu is the major user of Upstart, already has a
 heavily-patched src:dbus with considerable Upstart support code that
 didn't go upstream, and will be switching to systemd in future,
 how much benefit is there in having a native Upstart job for dbus
 in Debian? I'm concerned that the risks (and effort required) may
 outweigh the benefits.

 More specifically, is anyone volunteering to maintain dbus' Upstart support by watching bug reports and "owning" any relevant bugs? I'm not going to test this configuration, and if it causes RC bugs that aren't addressed by an Upstart user, I'd be inclined to revert it rather than spending time on it.

</blockquote>
i can subscribe to dbus package in debian.
</div></blockquote><div><br></div><div>I feel very stupid because I literally can not figure out how to subscribe to a package's bug reports in Debian. I have subscribed to the Utopia ML, though, and will watch for any problems with Upstart.</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote><blockquote> +stop on deconfiguring-networking
</blockquote>
</blockquote>
This is correct.

<blockquote> This appears to have caused some rather upset bug reports in Ubuntu
</blockquote>
These problems are unrelated to dbus package, and are not bugs dbus
job. Despite the confusing state the user's machines were left in =)))
It was a bug in upstart jobs in the ifupdown package which has been
resolved recently.</div></blockquote><div><br></div><div>I will change that back then.</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote><blockquote> +start on local-filesystems
</blockquote>
 Similarly, this doesn't necessarily provide /usr.

</blockquote>
    start on remote-filesystems

is emitted after /usr and all virtual filesystems are available (/run
et al). Maybe that's a better fit on Debian.</div></blockquote><div><br></div><div>Are you sure? man tells me that it is when all remote fs are mounted, which does not include local filesystems (e.g. a separate, but non-NFS, /usr). filesystem is what we want, no? Also, dbus needs /var because it does not use /run yet, so it needs filesystem anyway.</div><div><br></div><div>I have attached the changes (using filesystem, not remote-filesystems), and hope this can be merged soon, Simon.</div><br><div>Thanks,</div><div>--</div><div>Cameron Norman</div>