Andrey Rahmatullin writes:
> On Thu, Mar 09, 2017 at 12:22:17PM -0800, Russ Allbery wrote:
>> Sure, but hopefully we find and report those as bugs. I personally run
>> without recommends on Debian unstable on several different types of
>> systems and report these problem
Andrey Rahmatullin writes:
> On Thu, Mar 09, 2017 at 10:14:13AM -0800, Russ Allbery wrote:
>> If you don't want possibly unused software installed, we have a
>> supported mechanism for that: disable automatic installation of
>> Recommends.
> Which explodes from ti
e an easy way
for a library consumer to relax those dependencies as needed. But that
would require writing some additional infrastructure and relabeling all of
those libraries to have a new dependency field, and I strongly suspect
it's more effort than it's worth.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jonas Smedegaard writes:
> Quoting Russ Allbery (2017-03-09 04:24:09)
>> In general, I don't want to see us place too many restrictions on
>> Recommends. If you don't want additional helpful programs, disable
>> installing Recommends by default. I think it'
ULD ("this is normally not a good idea but may
be the correct thing to do in specific situations"), but we don't
currently have that.
This would definitely declare lots of existing packages buggy, which is
something we normally try not to do because usually packages are doing
this for some good reason (and I think that's obviously the case here).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
a bug?
> e2fsprogs -> libuuid1 -> uuid-runtime
> that daemon is useful only if you need to rapidly generate MANY uuids. Not
> just a single uuid per filesystem. If your package actually needs that, it
> can declare the dependency itself, like ceph-base does.
Here too, Recommends -> Suggests seems to make sense to me; is that a
conversation anyone has already had with the maintainer?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
is the most correct, and it's not
> written.
Yeah, it now makes perfect sense to me.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ben Hutchings writes:
> On Mon, 2017-02-27 at 16:09 -0800, Russ Allbery wrote:
>>> Daniel Pocock writes:
>>> However, at the time when I ran ntpdate, ntp was not running. I had
>>> brought up the network manually due to an interface renaming issue on
>>&g
Ben Hutchings writes:
> On Mon, 2017-02-27 at 11:18 -0800, Russ Allbery wrote:
>> The much simpler systemd-timesyncd doesn't set the hardware clock for
>> reasons that one may or may not agree with (I honestly haven't
>> researched it in any depth),
> It looks
yncs, that might fix the problem (alas, I forget the set
of command line flags that do the same thing as ntpdate).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
re clock but you still want to
set the hardware clock, you can add your own shutdown init script / unit
to run hwclock --systohc (or even a cron job if you want).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
o keep using it so far as I know.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
serious, and the maintainers can ask for stretch-ignore tags (or
downgrades for their specific bug if that seems more correct for specific
reasons related to their packge, whatever those may be) if they feel that
is appropriate.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
one wants to take a crack at that, probably for section 4
before 4.1 since it's really fundamental to the whole concept of source
packages, I'd be happy to review. (I could have sworn that we had an open
bug about this and some requirement other than the DFSG stuff in 2.2, but
I wasn'
Ian Jackson writes:
> Russ Allbery writes:
>> The point is that they don't randomly fail in the sense that they don't
>> fail n% of the time when run in any possible build environment.
>> Rather, in the subset of cases we're talking about in this threa
Holger Levsen writes:
> On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
>> This is, in a sense, an unreliable test, but it's not unreliable in a
>> way that directly affects the main line of package development.
> until someone affected wants to contribute…
e and on the buildd network, but fail
either reliably or randomly in other build environments.
This is, in a sense, an unreliable test, but it's not unreliable in a way
that directly affects the main line of package development.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ben Finney writes:
> Russ Allbery writes:
>> I really want something that will pass Lintian completely but that
>> dput will refuse to upload, which is what UNRELEASED currently
>> accomplishes.
> Wookey writes:
>> 1. I really dislike dch's enthusiasm for p
fuse to upload, which is what UNRELEASED
currently accomplishes.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
odule of the Node core
library that always returns false to isatty and throws not implemented
errors if ReadStream or WriteStream are called.
I agree that it's quite irritating that upstream didn't bother to put
something like that into any of the package metadata and rel
lly haven't).
Some upstream test suites also make it a little difficult to disable a
single test without carrying a patch. (Hm, including mine)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ts via
> NMU until the maintainer exits the hospital and can investigate.
That would certainly be fine, and I'm signed up for every "please NMU my
packages" list I can find, but we both know that time to do this for all
packages is pretty short in the run-up to the release.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
, flaky
failures that sometimes do fail on buildds *may* interfere with security
support, and therefore are, to my mind, much more serious.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
g specific and
people would expect Python 4.x to be just as disruptive as the 2.x to 3.x
migration.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
not hugely human-readable).
> "gbp pq" is probably way better then using quilt however.
I like it because quilt is a fairly primitive revision control system, so
while it has tools for rebasing patches, they're not very good compared to
git rebase.
--
Russ Allbery (r
branch should be equally accessible, and has some practical
advantages, but I do still work with upstreams who use Subversion, and I
*know* patches work.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Nikolaus Rath writes:
> On Jan 03 2017, Russ Allbery wrote:
>> Speaking as a Debian user who frequently has to apply local patches or
>> produce local versions of Debian packages for my job (usually weird
>> backports or bizarre local requirements), I cannot express to you
lease, but it's certainly way *easier*.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ssing something? I think the
rebased set of patches is far, far less useful if they exist only in my
Git repository and not in the Debian source package, but maybe git-dpm
puts them there as well in some way that I don't understand?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
and more
congenial and collaborative, even if you were also in the habit of sending
changes upstream. It eliminates the fear that you're also applying other
ugly hacks you're not telling them about that might be maintenance burdens
for them.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ems with shipping a Git repository
with all of its history to our archive network, which have already been
discussed at length.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
via other
mechanisms. The most time-consuming part is rebasing and squashing
related changes together into one coherent diff, but that's going to be
just as hard with any of these tools since the hard work is semantic and
requires thought, not just repository manipulation.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
patches against upstream. I really like
being able to just point upstream at all the patches relevant to them that
Debian has applied.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Niels Thykier writes:
> Russ Allbery:
>> I've done extensive benchmarking of this in Perl for a different
>> project and yes, fork and exec of an external compresser is *way*
>> faster than using a library. I suspect the Perl compress libraries are
>> making
d it out. [I didn't bother to benchmark them, because the
> differences between them was so stark.]
I've done extensive benchmarking of this in Perl for a different project
and yes, fork and exec of an external compresser is *way* faster than
using a library. I suspect the Perl compr
Nikolaus Rath writes:
> On Jan 02 2017, Russ Allbery wrote:
>> Furthermore, it forces a rebased, clean representation of the patches,
>> which I for one hugely prefer to the mess that you get if someone was
>> packaging in Git and just randomly commits things directly to th
ure for me.
But then, I'm a rebase-not-merge person in the perennial Git flamewar.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ut missing features in
Debian, I could always go implement such things if I cared that much about
them. :)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
d alias ifconfig to something
that reminds me to use ip to force myself to do the mental conversion.)
I apparently haven't gotten over my initial confusion when I ran into it
for the first time, but that isn't a good idea not to use the notation,
and I do see the merits. Hopefully
Tollef Fog Heen writes:
> ]] Russ Allbery
>> It's possible that some other tool has abused CIDR notation in this way,
>> but ip is still the only place I ever see it. It's definitely not common.
> I picked a few arbitrary networking platforms:
Meh. Okay, thanks,
Christian Seiler writes:
> On 12/29/2016 08:38 PM, Russ Allbery wrote:
>> ip address also has one of the worst output UI decisions I've ever seen,
>> namely this line:
>>
>> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
>>
>&g
notation (IIRC) invented by this
command, used nowhere else in networking, and confusing to anyone who has
prior networking experience.
This is all probably a matter of opinion, but Lars is definitely not alone
in considering all this stuff to be quite bad.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery writes:
> I will file a bug against reportbug on your behalf.
I think this bug may have been introduced in the Python 2 to Python 3
conversion, if I am understanding it correctly. Bug report is here:
https://bugs.debian.org/849586
--
Russ Allbery (r...@debian.
orien:~$ python3
| Python 3.5.2+ (default, Nov 22 2016, 01:00:20)
| [GCC 6.2.1 20161119] on linux
| Type "help", "copyright", "credits" or "license" for more information.
| >>> from email.mime.text import MIMEText
| >>> message = MIMEText(&#
find some way to name the wrong
thing in the command, refer to it incorrectly, or pick the wrong way to do
whatever I'm trying to do. And I use it so rarely that I never remember
what mistakes I made the next time I try.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
at affect
all subsequent updates, or delete their account to unsubscribe from all
bugs in one go.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
data point for two of my personal servers.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
s.
> My experience of using Vagrant for that purpose at $DAY_JOB was very
> successful. The main advantage, of course, is that each developer gets
> its own throw-away development environment.
I don't think this is an either-or. Both are useful in different
contexts.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
able in Ubuntu xenial, which is scheduled for 5 years of support,
> terminating in 2021.
It's in universe, so it's not really included in that five-year promise.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
disables TLSv1.1 and newer, at least as far as I was able to determine
from looking at the code while trying to solve another reported bug.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
the Shibboleth suite because
cURL is using 1.1, but xml-security-c and Apache both need 1.0.
I agree with Ondřej: the current transition state is not releasable. We
need to figure out something else.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
although it's a ton of
work for the release team when people don't pay attention, so please do
note the release timeschedule and coordinate your transitions!).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
course people might not want to work on that,
> which is fair enough.
Yeah, that's always been my thought process too, and then I've never
caught up on the backlog. :) Right now, I haven't had time to even start
the backlog. :(
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Holger Levsen writes:
> On Fri, Nov 04, 2016 at 03:03:09PM -0700, Russ Allbery wrote:
>> (We unfortunately don't have good language for this in Policy. Right
>> now, the must/should distinction conflates two things: severity, and
>> certainty. We used to have the s
occasionally represented with "must" in Policy right now.
It doesn't help that anyone from an IETF background will be used to using
MUST for certainty instead of severity.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bernd Zeimetz writes:
> On 11/02/2016 02:04 AM, Russ Allbery wrote:
>> There have been various efforts to aggregate tiny packages together
>> into larger packages in the past. I'm familiar with some of those
>> efforts on the Perl team. My impression is that, in ev
Paul Wise writes:
> On Wed, Nov 2, 2016 at 9:04 AM, Russ Allbery wrote:
>> If upstream themselves aggregates, then this works well. (See, for
>> instance, TeX Live, which is basically an upstream aggregation of
>> independently-released packages.) That gets its own vers
e to lots more
packages, I personally think the right path forward would be to fix things
that break in the archive to cope with this rather than to try to do
artificial bundling. I think people seriously underestimate just how hard
the artificial bundling is both technically and in all of the user
ings much easier (such as patching
Javascript for security vulnerabilities, which I expect to be an
increasing issue as the free software ecosystem uses Javascript more and
more heavily).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
aintain, sort of.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nning Debian stable and their security update status and policies on a
> silver plate to the NSA.
It's a tradeoff with freshness of security updates. Personally, I usually
use an in-house mirror of security.debian.org for various reasons, and
it's worth noting that our "discouraging" isn't particularly aggressive.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
nion service system.
> https://onion.debian.org/
> https://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/onion
Oh, interesting, thank you. I hadn't realized that. That definitely
makes Tor more attractive.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
iever in ubiquitous encryption, even if it seems silly,
just on the grounds of "why not?". We should encrypt reportbug traffic
too, if we can. Yes, a lot of the details get exposed at the other end
anyway (although not necessarily), but it's usually fairly trivial to
encrypt links, and if it is, there's basically no reason not to.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Adrian Bunk writes:
> On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>>...
>> The value of HTTPS lies in its protection against passive snooping. Given
>> the sad state of the public CA infrastructure, you cannot really protect
>> against act
*much* more expensive and *far* riskier step of moving to active
interference with traffic, neither of which nation-state attackers want to
do and neither of which they have the resources to do *routinely*.
It won't help if a nation-state actor is targeting you *in particular*.
But it helps immen
it, etc.). By comparison, the work for TLS is all on the
project's part, and then the end user just gets the benefit for nearly
free.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
from the size of the object downloaded, particularly if you can watch over
time and see what happens when updated packages are released.
Of course, it's much harder than just passively reading the HTTP GET
commands. It probably requires someone write code to map object sizes to
possible packa
r of something
much deeper and much darker than just a trivial mistake.
[1] https://en.wikipedia.org/wiki/Dog-whistle_politics for those
unfamiliar with this term.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
I'm not sure what people expect to see as a result when that's
the tone of the discussion?
I think people are trying to express a lot of frustration, so I'm trying
to be sympathetic, but that doesn't mean I think this type of criticism is
warranted, constructive, or a reasonable way to treat other people.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
to contribute occasional work but who don't want to incur the
obligations of letting Debian maintainer work turn into a second job.
(And yes, that means that we should be much more open to NMUs and change
our historical baggage around that. Please NMU my packages if there are
bugs I
rts, and I will look at and try
to resolve bugs against stable on those packages. But for something like
GNOME, it's unrealistic to expect much resolution of bugs only in stable
unless they're particularly severe.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
submitter,
which are later dashed. This is just bad all around, and it leads to a
lack of trust in the long run.
If no one is ever going to look at the bug again, just close it. It feels
more confrontational, but it's far more honest, and it doesn't create
unrealistic expectations. (Obviously, try to do this politely and
constructively!)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
log
entry. Anything other than that would require reading the bug log to
understand what happened.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
that the free software I provide is
provided as-is, with no express or implied warranty, and may not work for
you at all, and I do not promise to improve it or fix it in any way. It
may be awful. It may be completely broken. I may not fix it. The only
thing I promise is that it won'
pect* this to happen.
This is not the case.
Please don't be that entitled person who assumes other people are required
to volunteer their time to continue to help you just because they have in
the past. Instead, please treat gifts as gifts, accept them for what they
are at the time, a
in a conventional employee or contracting relationship, to compensate
for my loss of control over my priorities and the requirement to do a lot
of unenjoyable, tedious work to achieve things I don't care about at all.
When I do volunteer work in my free time, I am not bound by any of those
restrictions. That's *why* I do it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
fork unstable and not testing.
If they do that, they will have to deal with problems like this. Comes
with the territory.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
that could result in apt giving up on
an upgrade instead of finding the correct solution, or if the bug breaks
the package in some invisible but dangerous way (data loss, for instance).
In those cases, I might consider a versioned dependency to as an aid. But
I think it's something t
ay. Well, I think this is just obviously incorrect, so I suppose we're
at an impasse. But thank you for the explanation!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
action of the resources that you
seem to think we have, and we're just trying to be explicit about what we
can and can't do rather than having people's bug reports quietly disappear
with no response.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
that we will. It's simply not a goal of the project nor is it
something we have resources to do.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
ould not retain bugs that do not help us
achieve that. It would be great if it could also be a user support
channel, but this is just unachievable for a volunteer-maintained
distribution like Debian, and we should avoid creating the impression that
we promise to do this.
--
Russ Allbe
n we close bugs to general as
unactionable. Maybe we're just creating an attractive nuisance and should
shut it down entirely to avoid that frustration?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
orth the effort. Please let's
not pick fights that *aren't* worth the effort and will cause upstream to
look at us like we're paranoid nit-pickers. This sort of thing is really
bad for cooperation with other projects.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Lefevre writes:
> On 2016-09-08 08:44:54 -0700, Russ Allbery wrote:
>> That's a little better but not a lot better. It means that it's still
>> unsafe to run any script out of a world-writeable directory such as
>> /tmp, even if the sticky bit is set.
build (since this
is something to which the package maintainer should bring nuance and
deeper understanding, so you want the wiggle room of should).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
where I
was relying on this behavior and hadn't realized I was).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
seful for individual packages
than it is for large sets of team-maintained packages where you're more
likely to change Policy-related things across all packages at once.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jakub Wilk writes:
> * Russ Allbery , 2016-09-07, 09:26:
>> Now, that said, assuming that "fail" is not a valid host in the local
>> domain isn't a good assumption and makes the build fragile. My packages
>> that perform a similar test use the DNS name addrinf
rather
> than the "no network during build" policy thing (though I can imagine
> it'd be harder to file the bug).
"normal" is the correct severity, IMO. Even "important" strikes me as
significant severity inflation. And it would need a real just
Marc Haber writes:
> Russ Allbery wrote:
>> Debian historically tries to handle these situations by just providing
>> everything simultaneously. The debate over init systems is as heated
>> as it is because it's quite difficult to do a good job at supporting
>&g
t one approach is clearly better than the
other in all respects.
Debian historically tries to handle these situations by just providing
everything simultaneously. The debate over init systems is as heated as
it is because it's quite difficult to do a good job at supporting multiple
init systems.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
good
decisions. And we should be connoisseurs of good ideas, whatever their
source.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Vincent Bernat writes:
> ❦ 29 août 2016 05:00 CEST, Russ Allbery :
>> upstart supports a similar mechanism via the -Z flag, but it's (IMO) a
>> little less clean: the process sends itself a SIGSTOP when it's ready,
>> and then lets the init system send it a
Jonathan de Boyne Pollard
writes:
> Russ Allbery:
>> All other init systems except upstart [...]
> Psst!
> * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice
I think that... says the same thing I said? At least the only ones I see
there are systemd and
g similar even earlier.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
s I maintain. It's
really a better solution than the other available options (which, to be
clear, I also support as upstream, because that's my general philosophy on
such things).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
e from recompiling
things to remove small dependencies like libsystemd over your entire
lifetime.
Premature optimization is the root of all evil, to quote Knuth.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
pin up a test system just to be sure things don't break. But
the ask was to not explicitly yank support (that isn't unfixably broken)
and to merge reasonable fixes, and of course like any packaging quality
issue the more that you're willing to do, the more awesome that ma
al performance from using
swap.
Desktops and laptops are obviously a different issue with different
tradeoffs.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
601 - 700 of 3430 matches
Mail list logo
