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

On Tue, Nov 04, 2014 at 08:54:27AM -0800, Russ Allbery wrote: > Josh Triplett writes: > > > This result concerns me greatly, and I think the technical committee > > should take this into account when considering whether to flip the > > dependencies of libpam-systemd aroun

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

On Tue, Nov 04, 2014 at 08:17:52PM +0100, Christian Seiler wrote: > Am 04.11.2014 17:07, schrieb Josh Triplett: > > This isn't a complete showstopper, since most of the time people seem to > > debootstrap a standard system and then install additional packages. > >

Bug#797533: New CTTE members

On Thu, Sep 10, 2015 at 11:57:59AM -0400, Sam Hartman wrote: > >>>>> "Josh" == Josh Triplett writes: > Josh> Assuming that the "often results in FD" holds true, and that > Josh> this doesn't encourage snap judgements, this seems li

Re: Bug#733452: Minimal code for systemd protocol

Perhaps sd_notify(3) could, for clarity, explicitly say "The process receiving the datagram (e.g. systemd) may wish to use SCM_CREDENTIALS to obtain the process credentials of the sending daemon." - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a

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

e's decision, I would happily serve 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.

Re: Bug#727708: init system thoughts

nd clearer and more natural. So, in summary, upon initial introduction, I found systemd's model far more intuitive, both innately (in its use of socket activation and similar mechanisms to *avoid* dependencies) and as a more natural mapping to how the system, kernel, and hardware work. I hope

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

e 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 to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231051050.GA18715@leaf

Re: Bug#727708: init system thoughts

k even if your primary network is a wireless network managed by NetworkManager, and even if that network doesn't actually work until the user has logged in, assuming your service is not actually in the dependency path of the user logging in. Personally, I would automatically report a

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 t

Bug#727708: systemd-shim uploaded to NEW

lict with systemd. That would 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

Bug#727708: systemd-shim uploaded to NEW

On Tue, Dec 31, 2013 at 01:07:22PM -0800, Steve Langasek wrote: > On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote: > > Steve Langasek wrote: > > > Looking more closely, I find that one of the conflicting files is a > > > conffile > > > (/etc/dbus

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

ced the GNOME team to remove it. I certainly hope you find "volunteers" willing to do that kind of work increasingly hard 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: 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 gre

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: > > > > Ste

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

Re: Bug#727708: init system discussion status

t versus a hypothetical git-daemon-systemd, or a future gnome-session-systemd or gnome-session-upstart package (for whichever init system isn't the default). (Note that the latter would work better if upstart stopped conflicting with sysvinit, similar to how systemd can be installed without being in

Bug#727708: init system discussion status

On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote: > (Josh, is there some reason why you replied to the TC list directly > rather than the bug report ? You should send your messages to the bug > so they are filed, displayed and archived there. Thanks.) I don't subscribe

Bug#727708: init system discussion status

ld make that possible, allowing users to try out upstart by setting init= 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..

Re: Bug#727708: init system discussion status

dev work, it seems quite disingenuous to link to the above bug as an example of a problem with udev, rather than as a debatable controversy. Your summary in particular seems biased and misleading. - 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/20140105031019.GA14030@leaf

Re: Bug#727708: init system discussion status

r uglier than just patching the daemon, but as an exercise that actually does seem cleaner than 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

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

tomatically disable itself when use_lvmetad=1, which seems like the right way 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.d

Bug#727708: TC endorsement, political aspects

27;s a consensus that the TC resolution needs to say something about this, and in particular if none of the TC members favoring systemd would object to voting for a resolution that included it, then I'd suggest something closer to the above as a clear statement of *cooperation*, rather than a d

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

namic discovery of devices without the need for udevadm --settle or systemd-udev-settle.service; in the event 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.de

Bug#727708: init system resolution - revised proposal

a set of alternatives integrating with different init systems need not individually run on other 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

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 > > >to

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

ccept fixes that made their packages work for more people." Fixing 726763 just needs a "Depends" from the GNOME packages to reflect their dependency on logind and the suspend inhibit mechanism, which as stated in the bug log won't happen until the resolution of 727708. Meanwhil

Bug#727708: multiple init systems - formal resolution proposal

o effectively compete with systemd, precisely because of the requirement to support *all* init systems. Suppose upstart added compatibility for several of systemd's most popular daemon interfaces. L, as written, would prohibit daemons from depending on "either systemd or a

Re: Processed: block 726763 with 727708

offer. Patches that the maintainers find acceptable would certainly be cause to remove the block (and add the patch tag). See also Russ's very clear response, which I agree with wholeheartedly; thank you, Russ. - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists

Bug#727708: multiple init systems - formal resolution proposal

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

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 fo

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 instea

Bug#727708: Processed: block 726763 with 727708

pen for maintainers to reject even such simple changes as > this. Given that 726763 does not actually qualify as evidence for your conclusion here, do you have any actual evidence that maintainers will behave as you fear, rather than that maintainers are capable of ongoing cooperative development?

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

installed a new init but not yet rebooted into it. It'd be nice to have a solution to both of those problems. Perhaps we could (start the multi-release process to) augment dpkg to support special dependencies such as kernels and init systems, for instance. - Josh Triplett -- To UN

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

tems do not. In both cases, the question is the same: least common denominator, or actually using available functionality? (To forestall the obvious objection: "optional" is the same as "least common denominator", in that it effectively prevents *relying* on that functionality, and t

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

ot seem like it would extend to "management guis or addons". So, for instance, GNOME Logs, a new upstream project specifically designed to browse the systemd journal, could by the clarification above be considered part of the init system, and thus can depend on it? If so, I would be ve

Bug#727708: Call for votes on init system resolution

at first I wondered why there wasn't an equivalent of option 2 without the requirement 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.

Bug#727708: Call for votes on init system resolution

, for jessie and later > releases:") were marked simply as "Therefore, for jessie:". That seems > to dispose of part of your objection to L. Given this statement, and Ian's followup objecting to that language, might I suggest that there should be a version of the L

Re: Bug#727708: init system coupling etc.

eless, it's worth poking at the logic in the hypothetical, since it seems generally applicable to more 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.

e's support from the TC for a proposal of "maintain sysvinit compatibility through jessie, and support smooth upgrades", which ought to address the concerns that are motivating your urgency in addressing this issue. Passing such a resolution would then allow for a more prolonge

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

ical Committee believes that Debian's normal collaborative processes can successfully handle the ongoing maintenance and contribution of support for multiple init systems, and does not have a further statement to make about support for multiple init systems at this time." (Wordsmith

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

ing the prompting proposal, and keeping systemd-sysv as the first (preferred) 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 act

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

uld still explicitly boot with init=/lib/sysvinit/init on the kernel command line.) Nonetheless, as far as I can tell, libpam-systemd is *not* the package driving the systemd transition anymore. Does that address your concern, Russ? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-re

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 wrote: > > I conceptually dislike the user experience of switching init systems > > because the user upgraded some random package that, from their > > perspe

Bug#746578: More systemd fallout :-/

nit" transitional package additionally provides sysvinit itself via /lib/sysvinit/init, making it possible to boot 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 presen

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

emd-sysv by installing a desktop environment) separate from the question of whether upgrades from wheezy to jessie should switch from sysvinit to systemd-sysv (which as far as I can tell Steve is not objecting to, but Ian is). On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek wrote: > On Thu,

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

On Thu, 18 Sep 2014 17:14:01 -0700 Cameron Norman wrote: > On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett 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 an

Bug#746578: More systemd fallout :-/ [and 1 more messages]

On Fri, 19 Sep 2014 13:31:51 +0100 Ian Jackson wrote: > Josh Triplett writes ("Bug#746578: More systemd fallout :-/"): > > On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson > > wrote: > > > As I understand it from reading the threads in the bug and on > >

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

appropriate package, for the benefit of users with apt-listchanges installed. I would also propose introducing a separate alternative 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

Bug#746578: More systemd fallout :-/ [and 1 more messages]

On Fri, 19 Sep 2014 17:24:29 +0100 Ian Jackson wrote: > Josh Triplett writes ("Bug#746578: More systemd fallout :-/ [and 1 more > messages]"): > > Assuming that apt does the right thing with the dependencies reversed, > > yes. I outlined several specific scenari

Bug#746578: Dealing with the conflicting dbus policies?

emd. More 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.

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

es from sysvinit to systemd if the user has any system configuration for sysvinit that will no longer apply (modified /etc/inittab, modified /etc/init.d/*, etc). I'd prefer to avoid prompting on routine upgrades to systemd (without any such configuration), but as a one-time migration, it woul

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

On Sat, 18 Oct 2014 20:59:54 -0700 Russ Allbery 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 detect systems w

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

27;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 -- 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/20141020031036.GA21941@thin

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

On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote: > >>>>> "Josh" == Josh Triplett writes: > > Josh> - It can't check for generated lines for serial consoles or > Josh> similar; finish-install can generate various additional &

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

On Thu, Oct 23, 2014 at 08:49:20PM -0700, Cameron Norman wrote: > On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett wrote: > > On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote: > >> >>>>> "Josh" == Josh Triplett writes: > >> > >&

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

necessary? The freeze has not yet occurred, and I don't see any obvious reason why the TC needs to explicitly direct 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

ircumstances, 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 wrote: > On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery 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 > > understandi

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

he rationale I guess we could leave it > > out. > > Josh Triplette produced a helpful detailed review. Here is the > revised draft. s/Triplette/Triplett/ :) And thank you for the update. One minor (but semantically significant) issue below, caused by a typo in my original suggestion.

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:

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

On Tue, 4 Nov 2014 17:54:53 + Ian Jackson wrote: > I've been reading the messages from Josh about cgmanager etc., and [snip] Actually, I'd like to completely withdraw my concerns there, in light of some new information. Quoting Serge Hallyn, maintainer of cgmanager: &g

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

On Wed, 5 Nov 2014 11:49:45 + Ian Jackson wrote: > Ian Jackson writes ("Bug#746578: libpam-systemd to flip dependencies - > proposal"): > > So, I hereby formally propose the resolution text below. I intend to > > call for votes some time tomorrow. > >

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

ifying in the TC decision that the Depends shouldn't be hard-coded (what became clause 6 of the current proposal), I didn't just have versioned dependency changes in mind, but also package structural changes (on either systemd's or systemd-shim's part). I think

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

the committee asked itself to decide, and subsequently answered, just as with 762194. And whether you consider it an attack on a maintainer / maintenance team or not, it's unreasonable to completely ignore the consequences of your decisions. I share your sadness that this and many

Thank you for your work, Ian

retend the entire Debian 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

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

ch mitigations should be included in jessie, to ensure a smooth transition for Debian users. (Since neither (a) nor (b) above has actually made it into jessie, or unstable for that matter.) That said, such advice may be unnecessary and superfluous; I'd hope that's already the plan. &

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

On Wed, 10 Dec 2014 14:35:32 -0800 Don Armstrong 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&q

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? Conta

Re: Bug#762194: Please consider declining (was: Initial draft of affirming transition to systemd as default for #762194)

de. I'd like to see the TC more often saying "we support this work already being done" and almost never saying "we're going to go off and figure this out ourselves". Also, as far as I can tell, the committee has only one open bug remaining about systemd, not two. - Jo

Bug#769972: Draft new member ballot

ee slots, or if current committee members 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#741573: #741573: Menu Policy and Consensus

long before the XDG menu existed. That it no longer holds as much importants as it once 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 wrote: > On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette wrote: > > Sam Hartman wrote: > > That seems very unlikely to me. Diversity is an important part of > > Debian. I think it is likely that the TC

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

in the > membership of the TC, we should have a vote on who should serve as > chair. Given the term limits now in place, that would guarantee a > fairly regular need to vote on the TC chair. - 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 > > wrote: > > > - #795855 > > > Introduction of formal

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

;t go into Keywords, but many of the hints used in practice would make good Keywords. - "icon" requires substitution of a better icon format; consumers of .desktop files that can't handle current image formats could always translate it back, though adding support for current image formats provides more benefit for comparable effort. Finally, as a last resort, while option D says you can't ship a menu file if you also ship a .desktop file, you can still ship a menu file *instead* of a .desktop file, if you really want 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#797533: New CTTE members

m write and they're 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

Re: Fwd: Re: Debian Roadmap discussion ?

ts for exactly this purpose. - Josh Triplett

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 > merging reasonable contributions, and

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. The systemd package includes a n

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. > ExecStart and related argum

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 healthy > use of debian

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 writes: > > Josh> As another technical alternative, which I haven't seen > Josh> mentioned elsewhere in this thread or related bug reports: >

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

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#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 /usr/bin/node du

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 procedur

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

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

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

hink that is sufficient cause to make an adversarial NMU reverting a maintainer's intentional 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#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 communic

Bug#975075:

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 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 comm

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

ecosystems at different points on that spectrum. Your message gives me a great deal of hope and optimism for how Debian may tackle this problem. In particular, with my upstream Rust/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 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 libpa

Bug#976462: Bug#631985: Compress debug

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

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: > https://github.com/jwilk/lets-shrink-dbgsym/releases/download/20200708/buster-main-amd64-202007

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 .

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: >&

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 new

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 subj

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 project

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

  1   2   >