Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

r gzip to parse it" The x86-64 ABI is set. Feel free to make the case to the next architecture designer that their new ABI should have the dynamic linker in `/usr/lib`. That would *not* have the same downsides, as long as everyone agrees on a path. - Josh Triplett

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

k there are any areas of functionality that we shouldn't *evaluate* and consider possibilities in. That doesn't mean we should ever gratuitously change things without discussion and without taking input and use cases into account. - Josh Triplett

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

Johannes Schauer Marin Rodrigues wrote: > I just remembered a pending MR that I'd say is a little more important than > "good to have": > > https://salsa.debian.org/debian/debianutils/-/merge_requests/21 > > Without this one-line change, /etc/shells on merged-/usr systems will have > some >

Bug#994388: dpkg currently warning about merged-usr systems

On April 8, 2022 6:31:27 AM PDT, Wookey wrote: >If they want to prove that no patches for the current approach will >ever be accepted, that can only be done by engaging further. Yes it >will be hard work, but if it's not done we are just stuck. It sounds like at least one patch has already been

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, Mar 24, 2022 at 11:56:02PM -0700, Josh Triplett wrote: > On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote: > > It would appear that the situation has deteriorated further. dpkg 1.21.2 > > now issues a warning on all merged-usr systems: > > > &

Bug#994388: dpkg currently warning about merged-usr systems

On Fri, 25 Mar 2022 11:05:26 -0600 Gunnar Wolf wrote: > However, even given his attitude, I trust he would apply a correctly > done patch addressing the issue at hand. I just read the dpkg git commit (57e084a52e1ede33b7914c3e0357311ac370a186) that added this warning in the first place. Quoting

Bug#994388: dpkg currently warning about merged-usr systems

On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote: > It would appear that the situation has deteriorated further. dpkg 1.21.2 > now issues a warning on all merged-usr systems: > > Setting up dpkg (1.21.2) ... > dpkg: warning: System unsupported due to merged-usr-v

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, 24 Mar 2022 19:24:02 -0700 Sean Whitton wrote: > This is how I see it as well. Putting aside the postinst warning, the I > can't see anything the TC could do beyond what we've already done, until > there's a patch on the table. I'm glad to hear that the postinst warning is something

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, 24 Mar 2022 16:22:38 -0700 Russ Allbery wrote: > Luca Boccassi writes: > > > If it was possible to do it, it would have already happened, and we > > wouldn't be discussing it at all, it would have just been done. > > Has someone written a patch against dpkg that causes it to do the

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, Mar 24, 2022 at 01:24:39PM -0700, Russ Allbery wrote: > Josh Triplett writes: > > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery wrote: > > >> That said, I personally am disappointed that the folks who have been > >> pushing merged-/usr forward are wi

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery wrote: > I think this accidentally confuses the related states of "unsupported" and > "buggy." We know that merged-/usr is buggy, in that one can construct a > set of package operations that leave the system in an invalid state. We > have a

Bug#994388: dpkg currently warning about merged-usr systems

On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne wrote: > On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote: > > We should distinguish two senses of "supported". > > > > There is the sense of what Debian-the-project supports. That is > > specified in the TC decision. That is not

Re: Bug#994388: dpkg currently warning about merged-usr systems

Russ Allbery wrote: > I think the concern is less about the noise and more about the fact that > this will be perceived by users as an official declaration from Debian as > a project that their system configuration is unsupported, while > simultaneously this is the default installation mode for

Bug#994388: dpkg currently warning about merged-usr systems

On March 15, 2022 11:38:44 PM PDT, Sean Whitton wrote: >Hello Josh, > >On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote: > >> It would appear that the situation has deteriorated further. dpkg 1.21.2 >> now issues a warning on all merged-usr systems: >&

Bug#994388: dpkg currently warning about merged-usr systems

It would appear that the situation has deteriorated further. dpkg 1.21.2 now issues a warning on all merged-usr systems: Setting up dpkg (1.21.2) ... dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs. dpkg: warning: See .

Re: Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

Jakub Wilk wrote: > A few months ago I recompressed whole buster/main/amd64 to see what the > effect of ditching --compress-debug-sections would be. > > Raw data for this experiment is available here: >

Bug#976462: Bug#631985: Compress debug

time" versus "install debug symbols, debug, remove debug symbols until they're next needed". - Josh Triplett

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

On Mon, 30 Nov 2020 10:55:44 + Mark Hindley wrote: > On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote: > > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote: > > > #921012 is about changing network-manager to Depend upon "default-logind | > > > logind" rather than

Bug#971515: Status as of last tech-ctte meeting

st/Cargo hats on, I would love to work with you and others on questions of what software packaging could look like, and how to maintain the quality and curation *and* package availability of Debian in collaboration with other ecosystems of package and dependency management. Other potentially interesting questions: what are the assumptions that go into our current tradeoffs about shared libraries vs static libraries, and are those still the correct tradeoffs in all cases? Josh Triplett

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton wrote: > On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > > First, as a point of order (for which some authoritative guidance from > > the Secretary, CCed, would potentially prove useful): while the > > technical c

Bug#975075:

.] On Thu, 19 Nov 2020 11:40:20 + Ian Jackson wrote: > Josh Triplett writes: > > I do not believe it falls within the scope of the technical > > committee to override a decision already decided by a project-wide > > GR, > > No-one is asking the TC to override the GR. I

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton wrote: > Hello, > > On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote: > > I'd also like to address one other issue here. It would be easy to > > hypothesize, at this point, that some additional communication

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

ional change. > I'm afraid the effect of this is that the maintainers of this package > are making it impossible for other developers to enable support of > sysvinit. This is not the case. If the maintainers of this package decline to *integrate such support in the package*, that does not close off all paths to providing such support. Other paths to enablement would include separate packages, other network management software, or alternative distributions. I'm sure there are other potential alternatives as well. - Josh Triplett

Bug#947847: please install systemd-sysusers using update-alternatives

top.org/software/systemd/man/sd_booted.html > > else > > fi "exec", not "install". - Josh Triplett

Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

[Please don't CC me on responses, and please follow up solely to -devel rather than cross-posting.] Please note in the following mail that I'm raising this *exclusively* as a policy and procedures issue, *not* a technical issue. I would request that people *please* focus on the policy and

Bug#862051: Refer #862051 to ctte

On Fri, 14 Jul 2017 17:50:56 +0200 Tollef Fog Heen wrote: > === DRAFT Resolution === > The Technical Committee recognises that circumstances change in ways > that make previous resolution no longer appropriate. In 2012, it was > resolved that the nodejs package should not provide

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

clude hashes of all shipped versions of init-select.cfg or possible generated versions of it for various init systems, and if the file doesn't match one of those, move it aside to a backup location and provide a notice to the user that you've done so. - Josh Triplett

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

On Fri, Jan 13, 2017 at 10:04:34AM -0500, Sam Hartman wrote: > >>>>> "Josh" == Josh Triplett <j...@joshtriplett.org> writes: > > Josh> As another technical alternative, which I haven't seen > Josh> mentioned elsewhere in this threa

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

On Wed, 11 Jan 2017 13:51:27 -0500 Daniel Kahn Gillmor wrote: > Please do not do this to gpg-agent unless upstream is fine with this > change. I have more important things i want to consider divergence from > upstream about, and i don't think this particular scenario is a

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

On Wed, 11 Jan 2017 14:59:06 -0500 Sam Hartman wrote: > I'll note that the practice of hard-coding paths is fairly common. > > > One common cause for this is programs that don't want to rely on PATH > for calling exec. Systemd is a particularly interesting example. >

Bug#835507: Please clarify that sysvinit support decision is not going to expire

On Fri, 26 Aug 2016 14:14:25 +0100 Ian Jackson wrote: > Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support > decision is not going to expire"): > > I don't want to make a blanket statement that it's a bug not to include > > an init script.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

On Fri, 26 Aug 2016 12:55:56 +0100 Ian Jackson wrote: > So: would the TC please clarify that the decision that > > For the record, the TC expects maintainers to continue to support > the multiple available init systems in Debian. That includes >

Re: Fwd: Re: Debian Roadmap discussion ?

r exactly this purpose. - Josh Triplett

Bug#797533: New CTTE members

wrong? Huh."). Assuming that the "often results in FD" holds true, and that this doesn't encourage snap judgements, this seems like a very good idea to me. (That said, I would suggest in particular that the ctte exercise extreme caution if the bug log does not show evidence of a maintainer response that demonstrates an irreconcilable situation. The ctte should still be a *last* resort.) - Josh Triplett

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

to. Based on the above analysis, I don't see a single instance of menu metadata that wouldn't translate over to .desktop files. - Josh Triplett

Bug#636783: Bug#795855: #636783 - New bugs for individual issues

On Tue, Aug 18, 2015 at 08:23:44PM +0200, Steve Langasek wrote: On Tue, Aug 18, 2015 at 11:12:08AM -0700, Josh Triplett wrote: On Mon, 17 Aug 2015 15:39:06 +0200 Didier 'OdyX' Raboud o...@debian.org wrote: - #795855 Introduction of formal cloture vote for the TC - #795857

Bug#795855: #636783 - New bugs for individual issues

. Given the term limits now in place, that would guarantee a fairly regular need to vote on the TC chair. - Josh Triplett

Bug#741573: #741573: Menu Policy and Consensus

did is no reason to denigrate people involved with it. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150727220416.GA3716@jtriplet-mobl1

Bug#741573: #741573: Menu Policy and Consensus

On Mon, 27 Jul 2015 15:05:03 -0700 Josh Triplett j...@joshtriplett.org wrote: On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette j...@debian.org wrote: Sam Hartman hartm...@debian.org wrote: That seems very unlikely to me. Diversity is an important part of Debian. I

Bug#769972: Draft new member ballot

want to express preferences? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150303053629.GA23142@thin

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

://lists.debian.org/87mwc9gfsw@xoog.err.no I would suggest inlining this reference in the relevant paragraph, or at least making it a footnote right after that paragraph, rather than an endnote. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

On Wed, 10 Dec 2014 14:35:32 -0800 Don Armstrong d...@debian.org wrote: On Wed, 10 Dec 2014, Josh Triplett wrote: This doesn't seem like an accurate description of #762194. #762194 was not specificlaly a request for the TC to override the maintainers of init to change the alternative order

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

Thanks for the updates; the current version in debian-ctte git (as of commit e43bfb9cd1f6316ed01a58a4a248e82fc3825850) looks good to me. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Thank you for your work, Ian

repository all lives in git. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141119192100.GA4590@jtriplet-mobl1

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

that this and many other actions has driven Tollef away from the maintenance of a critical and difficult-to-maintain package. I do not, however, share your sanctimony. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble

Bug#746578: libpam-systemd to flip dependencies - proposal

will then prefer to pull in systemd-shim and keep the installed init system rather than switching to systemd-sysv. In your mail with Message-ID 21590.30193.479905.710...@chiark.greenend.org.uk, you said: Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - proposal): [...] s

Bug#746578: libpam-systemd to flip dependencies - proposal

versioned dependency changes in mind, but also package structural changes (on either systemd's or systemd-shim's part). I think the suggestion you made above fits entirely within the spirit of the TC resolution. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org

Bug#746578: libpam-systemd to flip dependencies - proposal

On Tue, Nov 04, 2014 at 07:47:05AM +0100, Christian Seiler wrote: Am 02.11.2014 06:59, schrieb Josh Triplett: Apart from that, I would still request that someone with the ability to produce a modified local mirror test the two critical cases mentioned in https://bugs.debian.org/cgi-bin

Bug#746578: libpam-systemd to flip dependencies - proposal

, or regarding dependencies on systemd.) - Josh Triplett Rationale (Constitution 6.1(5)): 1. Currently libpam-systemd (which is pulled in by quite a few dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'. 2. The effect of this is that installing some packages which depend

Bug#746578: libpam-systemd to flip dependencies - proposal

the release team here. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102054832.GA1167@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

circumstances, making breakage far less likely. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102055908.GA1250@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

On Sat, 1 Nov 2014 22:59:09 -0700 Josh Triplett j...@joshtriplett.org wrote: On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote: So, this is also the last call for anyone to explain what harmful effect this could have if they think it would have a harmful effect. My

Bug#746578: libpam-systemd to flip dependencies - proposal

and keep the installed init system rather than switching to systemd-sysv. s/intentionally do not have systemd/intentionally do not have systemd-sysv/ - Josh Triplett Decision (Constitution 6.1(4)): 5. We therefore overrule the decision of the maintainer of libpam-systemd binary package

Bug#765803: Status of prompting / notification on upgrade for init system switch?

}' | sed 's, /,\n/,g' | sed -n '/^\/etc\/init\.d\//s/^\([^ ]*\) \(.*\)$/\2 \1/p' | md5sum --quiet -c 2/dev/null | cut -d: -f1 ) (Note that md5sum exits with non-zero if any of the checksums fail, but since it isn't the last thing in the pipe, that doesn't actually matter here.) - Josh Triplett

Bug#765803: Status of prompting / notification on upgrade for init system switch?

On Sat, 18 Oct 2014 20:59:54 -0700 Russ Allbery r...@debian.org wrote: When one of you has a chance, could you update this bug with the current thinking around how to handle upgrades, around the ordering of dependencies in libpam-systemd, and some of the other ideas (such as attempting to

Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie

in the release notes. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141019050507.GA1086@thin

Bug#746578: Dealing with the conflicting dbus policies?

elaborate solution, if the above is undesirable for some reason: teach dbus to also reach policies from /run/dbus-1, and have systemd-shim ship an init script that symlinks a policy file there iff not booted via systemd. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org

Bug#746578: Reasons to keep systemd-sysv as the first alternative

On Thu, 18 Sep 2014 17:14:01 -0700 Cameron Norman camerontnor...@gmail.com wrote: On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote: I'm pulling a quote from the bottom of Steve's mail to the top, to call attention to a new and critical point that I didn't see raised

Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades

requesting an explicit unconditional prompt on upgrade; while not optimal, it would be easy enough to add, and still preferable to having a different default for upgrades than for new installs. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject

Bug#746578: Reasons to keep systemd-sysv as the first alternative

) alternative in libpam-systemd's dependencies. (Though, if a one-time unconditional prompt about upgrading to systemd would serve as suitable warning, I'd advocate for that; however, somehow I doubt that step would actually satisfy people calling for systemd's head.) - Josh Triplett

Bug#746578: Reasons to keep systemd-sysv as the first alternative

is *not* the package driving the systemd transition anymore. Does that address your concern, Russ? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918183435

Bug#746578: Reasons to keep systemd-sysv as the first alternative

On Thu, Sep 18, 2014 at 11:36:53AM -0700, Josh Triplett wrote: On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery r...@debian.org wrote: I conceptually dislike the user experience of switching init systems because the user upgraded some random package that, from their perspective, doesn't

Bug#746578: More systemd fallout :-/

sysvinit via init=/lib/sysvinit/init even with systemd-sysv installed. Michael Biebl is working on automatically adding a GRUB menu entry to boot sysvinit if present, which would make that even smoother. Hope that helps, Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org

Bug#746578: Reasons to keep systemd-sysv as the first alternative

tell Steve is not objecting to, but Ian is). On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek vor...@debian.org wrote: On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote: On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery r...@debian.org wrote: I conceptually dislike the user

Bug#746715: the foreseeable outcome of the TC vote on init systems

intended as roughly delineated positions, not rigid ones.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140522170138.GA7063@jtriplet-mobl1

Re: Bug#727708: init system coupling etc.

cases.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140214151322.GA20325@leaf

Bug#727708: init system coupling etc.

then allow for a more prolonged consideration of how to handle things post-jessie, as well as consideration of whether existing cooperative processes in Debian might be able to handle this isue given the time. Any particular reason *not* to do that?) - Josh Triplett -- To UNSUBSCRIBE, email

Bug#727708: Call for votes on init system resolution

for virtual dependencies, before realizing that this is already permitted and the TC need only refrain from adding restrictions. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive

Bug#727708: Call for votes on init system resolution

to that language, might I suggest that there should be a version of the L rider that includes the sunset provision limiting it to jessie, since there is clearly support for such an option? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe

Bug#727708: call for votes on default Linux init system for jessie

objection: optional is the same as least common denominator, in that it effectively prevents *relying* on that functionality, and thus forces the creation of a least-common-denominator fallback, which everything higher in the stack must then cope with.) - Josh Triplett -- To UNSUBSCRIBE, email

Bug#727708: Depending on an init to be pid 1 == depending on a kernel to be running

(start the multi-release process to) augment dpkg to support special dependencies such as kernels and init systems, for instance. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive

Bug#727708: call for votes on default Linux init system for jessie

as stated in the bug log won't happen until the resolution of 727708. Meanwhile, installing either systemd-sysv or systemd-shim (or having systemd installed and booting with init=/bin/systemd) fixes the issue reported in 726763. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ

Bug#727708: multiple init systems - formal resolution proposal

anything sysvinit lacks. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140201211229.GA13727@leaf

Re: Processed: block 726763 with 727708

very clear response, which I agree with wholeheartedly; thank you, Russ. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140201214218.GA13928@leaf

Bug#727708: multiple init systems - formal resolution proposal

On Sat, Feb 01, 2014 at 01:21:19PM -0800, Russ Allbery wrote: Josh Triplett j...@joshtriplett.org writes: It should be completely trivial to introduce a virtual org-freedesktop-login1 package (modulo any complexities introduced by interface versioning for new methods added

Re: Processed: block 726763 with 727708

On Sat, Feb 01, 2014 at 03:24:54PM -0800, Steve Langasek wrote: On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote: The block added above simply reflects the many comments from GNOME folks (and systemd folks for that matter) saying that they're waiting for the fallout to clear

Bug#727708: multiple init systems - formal resolution proposal

On Sat, Feb 01, 2014 at 05:23:11PM -0500, Steve Langasek wrote: On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote: In particular, in the case of GNOME, I don't see any package in the archive yet for a fork of logind that depends on systemd-shim instead of systemd, so there's

Bug#727708: init system resolution - revised proposal

Don Armstrong wrote: On Thu, 30 Jan 2014, Josh Triplett wrote: Ian Jackson wrote: Software outside of an init system's implementation may not require a specific init system to be pid 1, although degraded operation is tolerable. For instance, consider a gnome-session

Bug#727708: init system resolution - revised proposal

init systems, as long as the packages collectively meet the requirements of this section. [ For example, a package using systemd to launch a user session, provided as an alternative to a package that runs on sysvinit, need not itself run on sysvinit. ] - Josh Triplett -- To UNSUBSCRIBE

Bug#728486: Draft of Resolution for 728486 (lvm/systemd compatibility)

such changes fully obsolete the patch in question, the patch may be dropped. Does that sound reasonable? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org

Bug#727708: TC endorsement, political aspects

change to adopt what might be better alternatives). - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120174045.GA5829@jtriplet-mobl1

Bug#728486: Current patch for resolving lvm/systemd compatibility

to handle dynamic hardware detection in any environment that lvmetad can handle (anything other than a multi-host cluster, as far as I can tell). - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas

Bug#727708: init system discussion status

. Josh Triplett writes (Re: Bug#727708: init system discussion status): Clint Adams wrote: As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. Thanks for your intervention which is helpful

Bug#727708: init system discussion status

= on the kernel command line, and allowing packages to use upstart for purposes other than running it as init (for instance, for graphical session startup). - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas

Re: Bug#727708: init system discussion status

introducing a second process. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140105070553.GA15198@leaf

Re: Bug#727708: init system discussion status

). (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being init.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas

Re: Bug#727708: init system other points, and conclusion

On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote: On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote: Steve Langasek wrote: On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote: So unless the TC wants to remove a great number of packages from the archive

Re: Bug#727708: init system other points, and conclusion

On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote: On Wednesday, January 01, 2014 08:47:13 Josh Triplett wrote: On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote: On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote: Steve Langasek wrote: On Tue, Dec 31

Re: Bug#727708: init system other points, and conclusion

On Wed, Jan 01, 2014 at 09:37:24PM +, Ian Jackson wrote: Josh Triplett writes (Re: Bug#727708: init system other points, and conclusion): On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote: In other words, what you're saying is that not only [something about NetworkManager

Re: Bug#727708: init system thoughts

On Mon, Dec 30, 2013 at 10:37:42PM -0800, Steve Langasek wrote: On Mon, Dec 30, 2013 at 09:58:07PM -0800, Josh Triplett wrote: But in the real world, we have a lot of services that we just want to start in runlevel 2 and be able to trust that the network and disk are sorted

Bug#727708: systemd-shim uploaded to NEW

then, for instance, unblock systemd's ability to upgrade past version 204.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231091630.GA23112@leaf

Re: Bug#727708: init system other points, and conclusion

to come by. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140101041218.GA5505@leaf

Re: Bug#727708: systemd-shim uploaded to NEW

as an early-warning system for any breakage that occurs in other packages when used without upstart, and I'll happily volunteer to help maintain the systemd packages on an ongoing basis if that would help. Thanks again for all your work on systemd. - Josh Triplett -- To UNSUBSCRIBE, email to debian

Re: Bug#727708: init system thoughts

to *avoid* dependencies) and as a more natural mapping to how the system, kernel, and hardware work. I hope this writeup of my first impressions of both systems proves useful in some way. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe

Re: Bug#727708: init system other points, and conclusion

to be available in Debian for folks who want to run the init system that continues to create functionality so useful that the proponents of upstart are willing to do a huge amount of work in order to adopt most of it other than the init system itself. - Josh Triplett -- To UNSUBSCRIBE, email