one aspect of the
lifecycle, but still does not achieve the semantics you're arguing for in
the abstract.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Simon McVittie writes:
> On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
>> Luca Boccassi writes:
>>> It is correct as-is. VERSION_ID is meant to identify a release, not
>>> updates or point releases. A release as in, Debian Bookworm, or Fedora
>>
ling release with very
substantial caveats and limitations.
I do agree that it's often useful to be able to quickly determine if an
image is pointing to testing or to unstable.
> On Fri, 2 Aug 2024 at 04:00, Russ Allbery wrote:
>> Well, it's related to your example of the zoom
e use codenames in the archive structure and I am probably
overthinking this.
> What do you mean?!! It's right there!
> https://www.freedesktop.org/software/systemd/man/devel/os-release.html#RELEASE_TYPE=
> ...ok, ok, it's there now because I just merged it and regenerated the
> docs :-P
Thanks! This looks good to me.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Right now, it
requires substantial effort to read any thread that you have replied to
because I have to brace myself for judgmental, emotionally loaded, and
hostile-sounding language that gets in the way of understanding the root
disagreement and having a cordial and constructive collaboration.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ssion.
I did review the discussion #1021663 in the hope that I would find a
detailed technical proposal there, but your messages to that bug seemed to
focus on criticisms of the current behavior mixed with insults. I wasn't
able to find a proposal, but it's entirely possible I missed it.
ll ecosystem of packaging tools fits together. I
think the only way out for the /usr-merge transition specifically is
through, and until we finish that we're probably not in a good position to
absorb those lessons in a more comprehensive way, but I hope we don't skip
that step.
--
Russ
EWS.Debian files, not the full changelog. Any new
NEWS.Debian file entry for a package that you have installed is generally
worth reading, and this is the supported way (other than the Release Notes
for the full stable release) that Debian communicates major breaking
changes like this to u
s is a problem created by the maintainer and overriding the
maintainer will not help. Someone will have to do this work, and it is
very far from trivial.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
feel like we need to wait for the TC bug to be resolved,
since there is a standing TC decision to make /bin a symlink to /usr/bin
and we can always change our wording later if that decision changes, but
we need to wait for the buildd /usr-merge anyway, so either way I don't
think we'r
ame question about how to talk about those paths in Policy. I
therefore don't think resolution of this bug blocks on the TC bug.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Luca Boccassi writes:
> On Mon, 15 May 2023 at 02:26, Russ Allbery wrote:
>> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh,
>> major player in Linux distributions, and I'm not sure how much they
>> care about compatibility with anyone else.)
>
cosystem.
I realize it's not necessarily obvious that changing PT_INTERP for some
binaries is a big deal, in part because it's not even obvious that it's
part of the ABI. That's why people who are familiar with the ABI process
are jumping in to say "please don't touch that, this is a big deal to us."
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ularly for what seem to be annoyances of our own creation with known
workarounds.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Ansgar writes:
> On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
>> Caring about them isn't the same thing as doing everything they want.
>> We can both try to make things as smooth for them as possible and still
>> make design decisions about Debian that they
e thing as doing everything they want. We
can both try to make things as smooth for them as possible and still make
design decisions about Debian that they may disagree with or that may make
some property they want to maintain difficult or impossible. It's the
sort of decision we have to
ppy in the short term, which means
there's going to be a tense period where some folks feel strongly that
we're doing this wrong. But more discussion, unless it's about truly new
approaches, often makes that kind of situation worse rather than better.
We may have to just un
talking about within a single package.
Thanks, good catch. We've been dealing with this elsewhere as the other
replies pointed out, but we should update the wording in Policy to make
this explicit.
I'll open a separate bug for that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
f a
Debian package, and a compatibility symlink at the old path is needed,
the symlink must be managed in a way that will not break when /path
and /usr/path are the same underlying directory due to symlinks or
other mechanisms.
We've had that rule in Policy since May of
clear, that's not a great situation for those
systems to be in, since this mechanism is a bit fragile and probably not
as strong as one would like! But nonetheless we should be very careful
about taking any action that might break its historical properties.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
the ballot, so we can err on the side of
convenience to let proposers rewrite the options to whatever they want.
If that makes previously acceptable options unacceptable, other TC members
can always propose new options or reinstate versions of the previous
options.)
--
Russ Allbery (
leaner support for non-merged systems even if Debian itself will no
longer support such systems, and I don't think it would be *too*
challenging to do so. There's also just some super-minor stuff like tabs
vs. spaces, formatting of function signatures, etc., that I'm happy to
help clea
al without having working code, or at
least a very detailed architecture, to start discussing and analyzing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
g pieces are and trying to propose an
implementation design that could get some consensus, and flush out the
remaining problems. (To be clear, others have been doing more of that
than I have, but I think it's a bit inaccurate to say that I've only been
complaining and not trying
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 willing to leave dpkg in a known-buggy
>> state without attempting to patch it to fix
ocial) to fix
edge cases and maintain a high level of consistency and correctness.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Sam Hartman writes:
>>>>>> "Russ" == Russ Allbery writes:
> Russ> Switching terminology to completely leave behind the terms
> Russ> with ambiguous meanings isn't a bad idea, but if so we really
> Russ> need a term that captures
> consensus-based way is still possible?
If the relevant people required to implement a decision are willing to
tackle it that way, I am certainly willing to participate from the Policy
side.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
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 systems and
something that we have elsewhere said is a correct system configuration.
--
Russ Allbery (r...@debian.org)
Felix Lechner writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery wrote:
>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.
> I co-mai
ormat, I believe stems from different problems
with the 3.0 (quilt) format that are unrelated to the native vs.
non-native package distinction. I have no useful opinions to add on that
topic.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ame argument as
the replacement string, and thus will probably do nothing.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
write
one program that supports the syntax of both.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
not
versions of the same basic tool.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
/debian-vote/2021/10/msg00019.html
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
y someone who cares about the which utility and is interested
in handling bug reports and requests concerning it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
demoralizing to other people in the project who are not at fault for any
of the historical init system hostility.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ncy approach
mentioned above, there must be some straightforward path for a collection
of init scripts or a conversion utility to satisfy that dependency.
That's where the "project supports the efforts of developers working on
such technologies" part of the GR result comes in.
Just to be extremely clear, the dependency structure for logind feels
different to me and I don't have an opinion on that.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t Policy is specifying a requirement or
recommendation. In those cases, these words describe decisions that are
truly optional and at the maintainer's discretion.
This was intended to reflect the result of the GR.
The dependency structure for indicating a logind requirement is a more
com
ng to be challenging for Debian to continue to be that
universal toolbox, but I also think it's exciting and valuable. I still
want to try to achieve it, and I would rather adopt new strategies for
packaging that make life simpler and easier for packagers and allow us to
keep pace with more upstream packages than to reduce scope to only the
things we already know we're good at.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
en our support for embedded devices); coreutils probably should build
on a lighter-weight machine than Firefox requires. And it's possible that
multi-core may be a reasonable requirement for that "heavy package" tier.
If we do go down that path, though, it would be nice to add a
Martin Steigerwald writes:
> Russ Allbery - 28.10.17, 16:13:
>> There wasn't *anything* "left out" of that discussion.
> In my opinion this is a pretty bold statement.
> If everyone has been heard, noticed, felt and valued, if everything has
> been covered, t
very legal system, appellate
process, or conflict resolution mechanism known to humans fails at one or
more of those principles much of the time.
We should always try to do better.
We should avoid expecting ourselves to be superhuman.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ships.
There wasn't *anything* "left out" of that discussion.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
g the change
carried additional weight for me due to his past work on Policy.
It's probably also worth noting that I have a somewhat different approach
on how fast to commit changes. I'm a huge believer in lazy consensus and
in the power of reverts, so I tend towards committing
path forward, which doesn't make me a
particularly unbiased judge of consensus.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
of regardless of the outcome of the current GR. I have strong
opinions, but I also have great faith in the members of this project and
in the project as a community. Sooner or later, this will all be behind
us; in the meantime, I'm going to work on enjoying collaborating with all
the great p
month. I've actually been one of the
least active members recently.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
Russ Allbery writes:
> If that process leads to everyone reaching consensus on a different way
> to handle things (which would be my ideal outcome), that would be
> awesome, and we could then do nothing.
Or, to be clear, a consensus on doing things the way that they're being
tly what the alternate
world would look like before we could begin to evaluate it."
If that process leads to everyone reaching consensus on a different way to
handle things (which would be my ideal outcome), that would be awesome,
and we could then do nothing.
--
Russ Allbery (r..
lier decision meant, just in case anyone was confused.
> 2. Ignored evidence of ongoing work.
>(specifically, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#25)
> 3. Plowed ahead with a vote that decides a massively complicated
>issue with a grand total of 3 days of discussi
6.1(5)):
> 7. Our advice is that this change should be in jessie. If necessary,
>this view should be conveyed to the Release Team, after the change
>is in unstable, by filing an unblock request in the usual way.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
pgpUNJ75KUCX6.pgp
Description: PGP signature
fere with systemd with the current version. In other words, I
think the existence of the package on the system should be a no-op if the
system is booted with systemd.
That makes this a minor bug, but not something that's too serious.
Am I wrong about this?
--
Russ Allbery (r
t question will of course be
>consistent with the successful General Resolution option, whatever
>that may be.
> ===
I vote: Y, FD
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
pgpw0JZW3RrLP.pgp
Description: PGP signature
git. The result is below.
> I intend to call for votes later today.
This looks great to me, Ian. Thank you!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "
)
This looks fine to me.
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
understanding is that all of the possible harmful effects have been fixed
by various other changes.
--
Russ Allbery (r...@debian.o
(In other
words, omitting the statement of skepticism in favor of the more neutral
statement that we've been asked to rule on the topic.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with
I think you got bit by the Mail-Followup-To and your messages didn't make
it to the CTTE bug.
Tollef Fog Heen writes:
> ]] Russ Allbery
>> Thanks, Tollef! Okay, so there does appear to be a conflict here. It
>> sounds like your primary technical concern, not addressed by
Ian Jackson writes:
> Russ Allbery writes:
>> Thanks, Tollef! Okay, so there does appear to be a conflict here. It
>> sounds like your primary technical concern, not addressed by Martin's
>> mail, is that getting the dependencies right to install systemd on
>>
th of those decisions can
still be taken on their own, and that dependency order will preserve the
existing state. Did I get that wrong?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.deb
tood the context of your proposal, given
that, now that I re-read it, it sounds like you were aiming for a
resolution of #765803 all along. In which case I'm just confused, and
what I'm arguing about isn't even what you were intending. :)
--
Russ Allbery (r...@debian.org)
, we should do it in the
context of the current bug, not in the context of last February, and it's
not clear to me yet whether the TC even has actionable jurisdiction (in
that there may not even be a conflict).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.or
with fresh installs. That's
consistent with the other examples you list, where we've picked a default.
> The question of whether this should be done is already with the TC.
However, if the systemd maintainers end up agreeing with Martin, I think
that means there is no conflict and
sed in those threads?
I would be particularly interested in your take on the analysis that Steve
Langasek posted to the debian-devel thread on why listing systemd-shim as
the first alternative dependency for libpam-systemd makes sense and should
not cause any negative effects for systemd users
ollow their normal decision-making processes, so for this to be a TC
issue, I think we need some sign that process has failed in some way
before 2 becomes actionable for us.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-re
m first is
conceptually correct due to the implications for the various scenarios
Steve lays out, and we'll need to deal with bugs by assigning them to the
appropriate package and setting the severity of those bugs as is
appropriate.
--
Russ Allbery (r...@debian.org) <http://w
do it via some more deliberate and obvious method than pulling
systemd-sysv in via the dependency tree of some random package. The
partial upgrade UX for that is really bad, IMO.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE,
8/002.html
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
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/87siklefqy@hope.eyrie.org
ited in package dependencies for
> main
> FD
I vote A, B, FD.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
pgpbRnqK6lXOR.pgp
Description: PGP signature
being incomplete and primarily useful for generating a template that
requires subsequent work?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#45
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ.
Ian Jackson writes:
> As discussed at the meeting, I hereby call for votes on this
> resolution (text below).
> There are two options
>Y Issue statement about (multiple) init system support
>FD
I vote Y, FD.
--
Russ Allbery (r...@debian.org) <ht
Ian Jackson writes:
> As agreed on IRC, I hereby call for votes on the rsolution below.
> There options are:
> A libjpeg-turbo to become default libjpeg implementaton (1:1)
> B libjpeg8/9 to remain default libjpeg implementaton (1:1)
> FD
I vote A, B, FD.
--
menus for other applications that don't inherently
support the XDG menu system.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
, but the general discussion and
intent looks right to me. Thank you for drafting this!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
Don Armstrong writes:
> Does anyone else on the CTTE use org mode?[1]
I do, although I read the documentation in a spike to get far enough to do
the one thing I wanted to do, and haven't really expanded my usage beyond
that.
--
Russ Allbery (r...@debian.org)
eric
ties. It's used to select a winning option from the Schwartz set. Given
how Condorcet works, I don't believe there is a way to ensure the Schwartz
set always has only one member by manipulating the number of voters.
--
Russ Allbery (r...@debian.org) <http://ww
uble,
though.
> FWIW, I think policy should be distinguishing whether its
> recommendations are requirements for distribution (legal issues,
> dependency errors), proper practice (ie, it's a bug if you don't do
> this), or just a good idea to consider (a suggestion from exp
ubious of your desire for all of this to be Lintian
warnings, since I don't think that matches Lintian's current criteria for
warnings, but I do think that the severity of the missing man page Lintian
warning may be a little overstated at the moment. I have no idea how one
wo
rd, and am sorry that I've not been able to
drive that work. I had intended to be well into it by now.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscr
y formal statement. There are many, many, many things in
Debian about which the TC has not made any formal statement (deliberately,
and for the best).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.
tick with it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://li
hy the maintainer felt that way about
the upstart changes?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
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/87fvkrj4o4@windlord.stanford.edu
Bdale Garbee writes:
> Don Armstrong writes:
>> I don't have a problem with this myself; does anyone have a problem with
>> date -d'Thu May 22 17:00:00 UTC 2014'?
> Works for me.
Likewise, so far as I know at this point. There's a possibility that I&#
Jonathan Nieder writes:
> Russ Allbery wrote:
>> So, I think the questions before the TC are:
>>
>> 1. Should programs that make sense in the context of a typical DE (I
>>realize there's some fuzziness around this) all have desktop files?
> Ah, I compl
once we have that guidance, but I don't think
this is the place to decide how to do that or what the implications are
for all the other "should" statements in Policy.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIB
f those things too, and over time
I try to implement All The Things in my packages. But I also really
*enjoy* that sort of exacting attention to detail, and while that's a nice
quality for us to encourage, it's not clear to me that we want to make
that the bar to entry. And that&#
Ian Jackson writes:
> Russ Allbery writes ("Bug#741573: Two menu systems"):
>> I do think that "should" in Policy is stronger than that, and I don't
>> think just weakening "should" for all of Policy is the right solution
>> to this bug.
case, BTW. In that case,
Policy says that it is "recommended practice," which policy defines as
equivalent to "should." If anything, doc-base is probably less used by
end users than the traditional menu. (Personally, I think man pages are
more important than either, but man
art of the reason why this bug was raised in Policy in the
first place is that none of them have actually happened, and that didn't
seem that likely to change.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-
on of Policy that way. I do think that
is intended to say that the package maintainer should write one, and
that's the most common interpretation that I've seen in debian-mentors as
well. They're not *required*, no, but that's true of any should.
--
Russ Allbery (r...
27;t think this
is important for your package, or if you're just not interested in working
on it, you can ignore it, but you do need to merge patches if someone else
wants to work on it." That would probably be useful.
--
Russ Allbery (r...@debian.org) <
install or provide desktop files, find that their
program appears in the menus, assume they're done, and move on, and the
menu quality in other integrations like fvwm will keep declining. I
believe this has been happening for the past couple of years, although
that's based on a gut feeling a
building other packages. This allows packages that
actually need a specific version to Build-Depend on that specific version,
while moving most of the archive to a new version by moving the Provides
and then scheduling binNMUs.
--
Russ Allbery (r...@debian.org) <http://www.e
t;>> reply and suggest an alternate time.
>> As no one has replied, our next meeting will be next week on the 20th
>> at 17:00 UTC.
> Just a reminder that the next meeting will start in under 40 minutes.
I unfortunately have a conflicting work meeting (that just got scheduled
flict between Bill and myself, so I don't think it's appropriate
for me to vote.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
Thorsten Glaser writes:
> Russ Allbery dixit:
>> But when providing project-wide guidance, we have an obligation to
>> worry about the error conditions as well. If multiple logind
>> implementations do *not* materialize, or if they do materialize but
>> then people
eason that I'm missing, but it may be best to respond there instead to
make it easier for those following the proposed GR discussion to see.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.or
to motivate
anyone to volunteer to do it, and therefore we'll have to live without the
benefits of having them.
If that feels like an unacceptable outcome, well, I think the right
reaction is to go do the work so that this outcome doesn't arise. Not to
try to write project rules to for
and tactical cases in the voting system,
but maybe it doesn't if we fix the FD dropping issue that we specifically
ran into.
An alternative would be to have an explicit cloture vote in the case of a
dispute over adding more options to a ballot, or some other similar level
of indirection such
it, I at least now understand what
it means and what I would need to do with it as Policy Editor.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
pgpDvzkuzXUe5.pgp
Description: PGP signature
1 - 100 of 541 matches
Mail list logo
