Merge lp:~clint-fewbar/ubuntu/natty/upstart/add-serial-console into lp:ubuntu/natty/upstart
Status: | Needs review |
---|---|
Proposed branch: | lp:~clint-fewbar/ubuntu/natty/upstart/add-serial-console |
Merge into: | lp:ubuntu/natty/upstart |
Diff against target: |
71 lines (+59/-0) 2 files modified
debian/changelog (+6/-0) debian/conf/ttyS.conf (+53/-0) |
To merge this branch: | bzr merge lp:~clint-fewbar/ubuntu/natty/upstart/add-serial-console |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
James Hunt (community) | Needs Fixing | ||
Scott James Remnant | Pending | ||
Review via email: mp+46191@code.launchpad.net |
Description of the change
resubmitting merge proposal as the last one was stacked improperly.
adds serial console that only starts when console= is passed on kernel commandline, and which pulls those arguments out to set serial parameters.
Unmerged revisions
- 1293. By Clint Byrum
-
adding missed new conf file
- 1292. By Clint Byrum
-
debian/
conf/ttyS. conf: Run getty on the serial console. (LP: #702574) - 1291. By Scott James Remnant (Canonical)
-
* debian/rules: make sure apparmor-
profile- load is executable.
* debian/apparmor- profile- load: common AppArmor profile loading helper
which can be used by any upstart services, regardless of the state
of AppArmor (LP: #692801). - 1290. By James Hunt
-
Begin new release.
- 1289. By James Hunt
-
releasing version 0.6.7-1
- 1288. By James Hunt
-
Added myself as a maintainer.
- 1287. By James Hunt
-
* New upstream release:
- Added manual stanza.
- Added debug stanza.
- Added start_on, stop_on and emits properties.
- Added GoalChanged, StateChanged and Failed signals.
- Documentation updates. - 1286. By James Hunt
-
New upstream release.
Hi Clint,
This merge request only consists of a changelog entry?
Do you think it reasonable that we parse the console= line in Upstart
itself, and make the value of that available to jobs that want it.
What kind of consoles do we want to support? Do we want to support
multiple console= values? How does the kernel interpret this field
already?
I think this is a discussion you should start on the upstart mailing
list, because it seems like something we need "smart" handling for
built-in.
Scott