At the risk of being yet another unhelpful member of the peanut gallery,
I believe I see a way to resolve the impasse regarding the "T" and "L"
options on the previous draft resolution. I'm not a DD but I have used
unstable as my principal desktop OS since 1998, I've administered a
handful of
On Fri, Feb 7, 2014 at 5:39 PM, Steve Langasek wrote:
> On Fri, Feb 07, 2014 at 09:41:18AM -0500, Zack Weinberg wrote:
>> People have made various assertions about how difficult it would be to
>> port the necessary systemd components to run with some other init system,
>> or
I brought this up earlier in the discussion, but it appeared right in
the middle of the big argument about what to vote on, and so seems to
have gotten overlooked. I think this pair of requirements, both
grounded in what it's going to take to do upgrades from wheezy in a
clean fashion, might be a
As a Debian user I'm pleased to see the ctte taking proactive steps to
ensure that the merged-/usr transition will still allow smooth
upgrades from Debian 11 to 12 and 12 to 13.
As an upstream contributor to several pieces of software included in
Debian, and as someone with an interest in ensuring
As an end user I wish to register an objection to any solution to this bug that
makes it impossible for me to install a Debian system where, out of the box,
"rename" in the default PATH is the Perl rename. This is what my fingers
expect, and what dozens of non-packaged scripts rely on.
(I say
Package: tech-ctte
Severity: normal
X-Debbugs-Cc: z...@owlfolio.org
I formally request that the Technical Committee call a halt to the
merged-/usr transition until such time as all of the bugs in dpkg that
can, on a merged-/usr system, cause damage to the contents of the
filesystem (e.g. packaged
On Mon, Sep 26, 2022, at 4:30 PM, Sean Whitton wrote:
> I believe that this request is invalid, for two reasons:
>
> - the specific things you ask for are all or mostly things that we think
> are currently up to the Release Team, and the TC cannot override
> delegates
I'm surprised to hear you
[Procedural note: I’m very busy with my day job this week, so I will
be responding to messages related to this report in batch mode, once a
day.]
On Mon, Sep 26, 2022, at 4:49 PM, Sam Hartman wrote:
>> "Sean" == Sean Whitton writes:
>
> Sean> - you might be lacking the full context of TC-
On Tue, Sep 27, 2022, at 4:23 AM, Matthew Vernon wrote:
> Thanks for bringing this to the committee; even if Sean is correct that
> we won't act on this report, you've described the issues clearly and I
> think it was worth bringing to our attention.
Thank you for saying so.
> As Sean says, thoug
On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote:
>> I'd like to make sure that the bug submitter has not identified
>> something new here.
>
> I've not seen any new issues appearing since the last round I file bugs.
I wasn’t aware that you have been filing bugs related to the
transition
On Tue, Sep 27, 2022, at 12:25 PM, Andreas Metzler wrote:
> On 2022-09-27 Zack Weinberg wrote:
> [...]
>> What I am asking for is a schedule change: specifically, that the
>> merged /usr transition not be allowed to proceed past the status quo
>> as of two weeks ago (i
On Tue, Sep 27, 2022, at 4:12 PM, Sebastian Ramacher wrote:
> On 2022-09-27 10:26:36 -0400, Zack Weinberg wrote:
>> On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote:
>> >> I'd like to make sure that the bug submitter has not identified
>> >> somet
On Wed, Sep 28, 2022, at 1:40 PM, Helmut Grohne wrote:
> Hi Zack,
>
> On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote:
>> I thought about this a bunch yesterday evening and I believe I see a
>> concrete scenario that can cause problems but is not covered by the
&
On Wed, Sep 28, 2022, at 5:08 AM, Svante Signell wrote:
>
> You can easily revert any system having usrmerge installed with dpkg-
> fsys-usrunmess. This should be known by all Debian users, by some
> suitable channel.
Having used it myself a couple of times, I would question "easily". If all
goe
On 2022-09-28 2:16 PM, Russ Allbery wrote:
"Zack Weinberg" writes:
1. Is there already a rule (or multiple rules) somewhere that forbids
the existence of pairs of packages where one ships /X/Y and the
other ships /usr/X/Y, where X is a directory on non-merged-/usr
sys
15 matches
Mail list logo
