are more important to them than cross-distro
compatibility, and given their goals, that seems like an entirely
reasonable decision. I would disagree vehemently with that decision for
Debian because Debian is not Guix.
In other words, it depends.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
nt question than the one discussed in this
thread.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
something that would be in scope for the Linux Test
Project, though, and it's possible their existing tests do some of this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t discussion) page 84. I'm not sure if there's a
newer version, since that one is labeled draft.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
back in at this point.
Luca Boccassi writes:
> On Mon, 15 May 2023 at 16:18, Russ Allbery wrote:
>> Note that we're not talking about complicated packages with lots of
>> runtime like, say, Emacs. As I understand it your proposal wouldn't
>> change PT_INTERP for that
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.)
> T
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/>
es 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 t
ng 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 make on a case-by-case basis.
example, if local system administrators have been deactivating systemd
units by diverting them, at first glance I think it would be better to
clearly tell them that they should stop doing this and instead use
masking rather than writing code to try to ensure this continues working.
--
Russ
r time. Whether or not we end up agreeing that is
true, this is a valid topic for discussion, and sometimes it is feedback
that other developers need to hear so that they can do some introspection
and evaluate whether that may indeed be the case.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
rked at some point, but
it's for an old upgrade so I don't know if it's still working. I think
it's more common to prompt in postinst during configure. I know of
several packages that do that, although it's not considered ideal if you
can avoid it.
--
Russ Allbery (r...@debian.org) <
sn't
a great architecture and there were better ways to do it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e uploads is not
available via dgit.
But it does provide at least upload-level granularity as a Git history for
every package, even those maintained with no version control system at
all, with the option for each package maintainer of opting into providing
more.
--
Russ Allbery (r...@d
Perl community already has some tools to deal with them, and I have
additional Perl modules in my gnulib-like collection of helpers that I
copy into my packages.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Wouter Verhelst writes:
> On Wed, Feb 22, 2023 at 08:20:27AM -0800, Russ Allbery wrote:
>> Unfortunately, it's often against the upstream license.
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the
Paul Wise writes:
> On Wed, 2023-02-22 at 09:47 -0800, Russ Allbery wrote:
>> People doing this should be aware that you're probably waiving certain
>> damage provisions in US copyright law should you ever sue someone in
>> the US for violating the license on the Debian p
yright expiration, which
decreases the value of that information.
People doing this should be aware that you're probably waiving certain
damage provisions in US copyright law should you ever sue someone in the
US for violating the license on the Debian packaging, at least so far as I
understand US co
es about). But dropping the copyright dates from the upstream notices
I think would often technically violate the upstream license depending on
its wording.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
is the logical spot?
I think your argument is that maybe you shouldn't have a bunch of
configuration the user can't change, and I agree!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ling to ucf or something similar that has built-in
functionality to try to handle cases like this.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ed with "the package gets lots of love but is so popular that
there are a ton of bugs of dubious quality that no one is looking at,"
which is less useful as an indicator).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ent of one of those email autoreplies that says "this mailbox is
unattended and no one will ever read your email." :) And, to be honest,
if that's the reality of the situation, maybe better to know than not!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
it's pretty clear from this discussion that the current Policy
wording is not sufficient, and we shouldn't have ambiguous language over
something as central as what build dependencies packages need to declare.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
gs. Sometimes it's more important
(because we're trying to retire a package for the next release); other
times, it's not, such as here.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ototyped for users. Traditionally, we
don't consider that an ABI break worth bumping the soname unless we have
some reason to believe that software is using those symbols.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Jonas Smedegaard writes:
> Quoting Russ Allbery (2022-12-15 17:41:15)
>> This is why I don't agree with Jonas: yes, there *are* other ways to
>> achieve the same goal, but they're more complicated and harder to
>> explain. The user experience of this build profil
this build profile looks a lot simpler and cleaner.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
he beginning of next week.
I think that seems fine baesd on my reading of the thread, although since
we have now found the configure.ac, I would also stuff that in the Debian
package somewhere so that all the pieces are available to someone who has
the Debian source package.
--
Russ Allbery (r..
he bug severity
should be based on how much of a problem that is in practice.
(I think this is mostly a long-winded way of saying the same thing Marco
said.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t,
and then pin it with apt-mark hold libnet-ssleay-perl until you're ready
to upgrade it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ecause shared /tmp is a surprisingly
tricky security challenge.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
could turn off in apt.conf). I have no idea how easy that would
be to implement, though.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
onfigured but don't
add the new firmware section, everything will appear to work but you won't
get new firmware, so the problem may go unnoticed.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Steven Robbins writes:
> On Sunday, September 25, 2022 4:57:19 P.M. CDT Russ Allbery wrote:
>> If someone sends mail from a domain that says all mail from that domain
>> will always have good DKIM signatures, and if the signature isn't
>> present or doesn't validate the ma
sage in the way that bugs.debian.org needs to do (adding
the bug number to the Subject header, for instance) usually breaks the
signature.
If you send mail from a domain that has a more relaxed (or no) DMARC
configuration, then your mail will go through fine and you'll not see the
problem.
--
Russ Allbery (
we're doing and how it's supposed to work (and what packages need to care
about it).
If possible, could you write up a brief description along those lines and
open a bug against debian-policy with that description? We can then
figure out where to put it in the document.
Thanks!
--
Russ
n't to restrict what you look at as a human
being doing work; the point is to discuss when you can take a special
blocking action rather than take a normal RC bug reporting action.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
on the grounds that it catches some number of RC bugs.
The project may, for example, decide that yes, this process catches some
RC bugs, but the number of bugs caught are not worth the other impacts of
that process, and the RC bugs can be dealt with via other means.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
e and effort, on an ongoing basis, working around problems
that upstream has wisely avoided and doesn't think should need to exist.
It's very hard to find motivation or volunteers for that kind of work!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
enough when it happens between releases, although in that case
sometimes we live with it as the least bad option.)
[1] https://www.debian.org/doc/debian-policy/ch-files.html#binaries
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
l produce a binary called asdf, but cl-asdf does
have an info page named asdf, so there's some potential for confusion
there. (cl-asdf and python-asdf narrowly avoid having a conflict over
info pages already.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Vincent Bernat writes:
> On 2022-07-14 17:14, Russ Allbery wrote:
>> (Also, due to the limitations and history of naming conventions, the
>> software is inherently trying to map into a gender binary, which if one
>> is attempting to capture self-identification is l
nder in any way other than simply asking people. :)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ke the percentage of the total software ecosystem that Debian is
packaging is smaller than it used to be (we've grown but free software has
grown way faster) and most of the places where I'd expect contention to
happen are handled by language packaging teams that probably have their
own p
me what went wrong.
My recollection is that if the signature on the upload is invalid, we
intentionally delete the upload with no notice (because we have no
confirmed knowledge of who to notify). It's possible that my information
is dated, though....
--
Russ Allbery (r...@debian.org)
distribution, and they've opted into sharing that information with us.
That said, I'm not sure that anyone uses that information right now, which
may make this a weak argument.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
idea to me.
Using an additional binary package control field felt weird to me, and I
wanted to believe there was some better place to put this information
rather than introducing yet another boolean control field, but after
thinking about it for a bit, I couldn't think of any better place tha
dn't
arrive at a clear conclusion.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
retty explicit
that the choice of directory layout in /srv is entirely up to the local
administrator and distributions should not be messing with it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
a
command-line or configuration argument. It's weird for that sort of
configuration parameter, which administrators are going to want to
customize, to be hard-coded into the package (and for me it raises
questions about its general code quality).
--
Russ Allbery (r...@debian.org)
is is going to be the solution, it has to be WAY easier to do.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
in this direction of
ballot construction.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Jonas Smedegaard writes:
> Quoting Russ Allbery (2022-04-19 19:29:09)
>> We need some way to clearly label non-free firmware packages so that
>> you can apply whatever installation or upgrade policy locally that you
>> want to apply, but solution #5 provides that by
y installer or not), but you could
remove it, of course. (I suspect you, like me and probably most other
Debian contributors, make pretty extensive modifications to the installed
package list after installing a new system, and have lists of packages
that you always add or always remove.)
--
Russ Allb
"3.0 (quilt)"?
3.0 (quilt) always has two tarballs, one for the upstream source and one
for the Debian packaging. 3.0 (native) has a single source tarball, which
I think is the desired goal here.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
filing for the first three categories seems like the change
with the biggest potential to benefit Debian, since it's a direct
simplification of the number of ways packages are maintained in the
archive. The packages without any patch system feel a bit less
interesting.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
titution. We don't have a provision for making minor changes apart
from the normal amendment process.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
d (b)
expose the information that we did have to gather in a standard format so
that other people can similarly have less copyright in *their* life by
automating their pain as well.
But to be very clear, what I'm hoping to get out of this is less time
spent on copyright and licensing, not mor
Russ Allbery writes:
> I can tell you from prior experience with DEP-5 that 3 is wildly
> controversial and will produce the most pushback. There are a lot of
> packagers who flatly refuse to even use the DEP-5 format, and (pace
> Jonas's aspirations) I don't expect that to change a
EP-5, and we can reach
an organic consensus without anyone feeling like they're forced to change
how they do things.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
as a Policy Editor, the way that Stephan is engaging with this
process is fine. We're in the early stages of discussion and
understanding the shape of the problem. Writing emails ot debian-devel,
and writing a DEP, are exactly the right way to engage with Policy on this
topic right now.
--
Rus
tives on the critical issues.
Exactly. We're not going to catch everything, to be sure, but we're not
catching everything *now*, and improvements of automation scale in ways
that trying to do more painstaking human review do not.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
iting those choices consciously from time to time.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
to me like
evidence that this task is not as important as we think it is.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Scott Kitterman writes:
> On Tuesday, February 1, 2022 12:18:07 PM EST Russ Allbery wrote:
>> Wookey writes:
>>> For what it is worth I concur with everything that Russ has written,
>>> and would like to have us look at this again (and that's honestly not
>>
Andrey Rahmatullin writes:
> On Tue, Feb 01, 2022 at 09:18:07AM -0800, Russ Allbery wrote:
>> I would hate to entirely lose the quality review that we get via NEW,
>> but I wonder if we could regain many those benefits by setting up some
>> sort of peer review sy
for new packages that is less formal and less
bottlenecked on a single team than the current NEW processing setup.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
I'm not sure that the ftp-master review reduces the
likelihood so much as to change the risk analysis that much. (But that
could well be a point of disagreement.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
likely is it that we wouldn't be able to remedy it without much cost if we
acted promptly? This is less a question about the specific language of
the law and more a practical question of how the law works in the real
world, something that a lawyer would be better-qualified to weigh in on.
--
Rus
l*, and we
would of course continue to hold ourselves to the same high standard that
we always have, we're already doing far better than the industry norm.
But a lawyer would have much more concrete experience and would be able to
provide a far better analysis.
--
Russ Allbery (r...@debian.org)
solving it." In other words, pretty much exactly the
policy we use right now for security issues, which I suspect are far more
dangerous to Debian users on the whole than copyright and licensing issues
(although both are important!).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
admit that I haven't done a survey) is that Files-Excluded
is less frequently used for cases where upstream has not done license
verification and is more frequently used for cases where upstream
disagrees with Debian over what is and is not free software. (IETF RFCs
are a sadly common example.)
--
Rus
design for the
problem we're trying to solve.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
uot; condition,
Policy expresses no opinion on a dependency versus an embedded copy,
either for or against.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ev where it will become outdated when GLib changes.
Yes.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
t be used 95% of the
time.
This is what I already do for libremctl-dev, for example. (Well, I list
the libraries required for static linking in Suggests currently, but I'm
not sure that list is complete any more and should probably just drop it
completely.)
--
Russ Allbery (r...@debian.org)
t using the same syntax than other debian/* files
>(rfc822 + "# comments")
I have no detailed feedback on your proposal, but just wanted to say thank
you so much for doing this. Being able to write a uscan file using a
clear key/value syntax will make me very happy.
--
Russ Allb
stead so that it's not marked as a configuration file?
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ing existing systems is even more important than that, and
I'm worried about our ability to do so if we put the machinery in
base-files.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
to dpkg
--add-architecture, which feels like a good model (although as you mention
I don't think we want --remove-architecture).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Well, bootstrapping a new Debian system involves running a tool that
> bootstraps a new Debian system. I think you're constraining the problem
> too much.
> It's a nice property that everything on the system comes straight from a
> Debian package, but it
ith the caveat as mentioned above that writing the
necessary filter may be difficult.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r to reason about the behavior or test it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
tion to try to find patterns that might cause problems, and to ask
all maintainers to remember this rather obscure rule, when we could just
fix dpkg to make the problem go away.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s required when there's a new
major OpenSSL release (and are far, far less significant than, say, the
differences between the OpenSSL and GnuTLS APIs).
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
mprove
GnuTLS, switching to OpenSSL is a lot easier and makes most problems like
this go away.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
ttempt to
standardize on NSS a while back? I feel like that didn't work and they
stopped that effort, but some quick searching didn't uncover any support
for that belief.)
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
hange without a GR to be sure the
project is behind it feels like the kind of thing that's likely to spawn
endless arguments that will sap everyone's will to live.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
API versions, then it's all the more
> important that the tests run against the Debian versions of the
> dependencies.
I believe the dependencies in question are test dependencies. In other
words, they're dependencies required to drive the test suite machinery,
not dependencies of the code und
dfsg.N-1. It's not consistent with the other places
where we add suffixes, such as backporting and stable updates.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
packaging to remove
non-free source removes functionality as well, this leaves version space
for users who need that functionality for whatever unfortunate reason to
package upstream's release as-is and have that version be later than
Debian's version.
--
Russ Allbery (r...@debian.org)
semantics, the
standardized command is command -v, but it doesn't do quite the same thing
in quite the same way. If you want which, you have to live with the fact
that it's not portable and different which implementations behave in
different ways.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Russ Allbery writes:
> Please do not do this. I do not want to have to reason about the
> security impact of someone who controls local DNS taking over my apt
> sources.
Incidentally, this is also exactly why I believe we should be using https
by default, so that a compromise of the
e machines.
We should not enable people who control the local network but not the
Debian system to dynamically change security-relevant configuration of
that system, which I believe includes apt sources, without explicit
permission.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
s.
Yes. For example, the approach used by apt-cacher-ng works fine.
Explicitly opting in to a local cache seems desirable.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
prefer the text/*
behavior most of the time, but I'm also not a typical user.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
r. But that's clearly a
> lot of work, and this change wouldn't preclude it.
This does seem like clearly the right solution in the long run for all
problems of this sort, though. I wouldn't want to add many statically
allocated UIDs. (But if anything qualifies for one, _apt is a reasonable
candidate
going to make you even more unhappy. In order to break this
deadlock, I think we have to have a design discussion in the shared space
of mutually agreeable solutions and not (on all sides) retreat back to a
single preferred architectural decision and only point out the problems
with any other approach.
101 - 200 of 4303 matches
Mail list logo
