Sven Joachim writes:
> On 2014-09-05 23:50 +0200, Russ Allbery wrote:
>> That seems much higher than I believe is the case. Wasn't there a
>> detailed analysis of this posted a while back? My vague recollection
>> was a number more on the order of a quarter of that,
ere a
detailed analysis of this posted a while back? My vague recollection was
a number more on the order of a quarter of that, and with most of those
being quite small (such as libsystemd-daemon0, which counts as a package
but which has an installed size of 72KB).
--
Russ Allbery (r
tracking and privacy leak points in
the process.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.
ient -CApath /etc/ssl/certs -connect www.paypal.com:443
I suspect a transient bug with PayPal's web site, possibly only affecting
some regions.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debia
hing listing
which packages were added or removed and their sizes, as well as the total
installed size of each of those sets. I think that would be more
effective and more directly on point than mucking about with trying to
monitor priority changes.
--
Russ Allbery (r...@debian.org)
Gerrit Pape writes:
> On Sat, Aug 30, 2014 at 09:30:17AM -0700, Russ Allbery wrote:
>> Also, I'll reiterate what I said on debian-policy on this topic: the
>> current Policy discussion of priorities is deceptive, since it implies
> I don't think the discussion on the
package maintainers. Policy discussion of
priorities really needs some substantial revision to account for that, for
the fact that conflict-free optional has not realistically been a project
goal for some years, and to be clearer about just what we want to use
priorities for.
--
on't know for certain
I don't care about.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87sike20pr@hope.eyrie.org
ould we include rules that match lines like:
Aug 28 07:30:01 lothlorien systemd[1]: Starting Run anacron jobs...
Aug 28 07:30:01 lothlorien systemd[1]: Started Run anacron jobs.
or should those be in the anacron package / rule set? I could see an
argument either way.
--
Russ Allbery (
27;t be too much work.
> And do we really want to install those logcheck rules files (conffiles)
> on everyones system, if only a small percentage of users actually
> install logcheck.
Lots of other packages already do, and the logcheck maintainers had been
pushing that as best p
Brian May writes:
> On 24 August 2014 04:24, Russ Allbery wrote:
>> Right, exactly. That's super-annoying to do if you were keeping
>> everything mixed together in the master branch, much easier if you were
>> keeping separate branches for each fix but keeping tho
Matthias Urlichs writes:
> Russ Allbery:
>> It's somewhat harder to maintain, but it's vastly better for
>> communicating to upstream or to other distributions.
> Mmh. Whenever Upstream uses git, my favorite method of sending a patch
> is to put the fix in a se
ing getty and so forth and instead using a simpler root
password verification mechanism. Linux traditionally brings up more
services in single user than, say, Solaris (such as networking), but I
think even Solaris didn't keep the root partition read-only when booting
single-user.
--
Russ Allber
ommunicating to upstream or to other distributions.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a96x6vhw@hope.eyrie.org
header can now represent the branch
information so that people can use whatever convention they wish and our
tools can still interoperate.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists
Thomas Goirand writes:
> On 08/18/2014 01:36 AM, Russ Allbery wrote:
>> The upstream source *can* be changed and improved for everyone.
> Truth, but not always practical. If I was going to fix all the defects
> of software I package, I don't think I'd have enough time
Thomas Goirand writes:
> On 08/18/2014 01:49 AM, Russ Allbery wrote:
>> Joey took various approaches to work around this, including shipping
>> some of the older versions of the compressors in the package. However,
>> the issue also applies to tar, and so far has been addr
configuration setups (as long as there's still an option to override
for local needs). So while more work that option makes the software
better for everyone in the long run.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIB
ed with a compatibility patch in tar.)
If you are absolutely relying on pristine-tar as the only source for a
file, you may be more concerned about the possible incompatibilities with
future tool revisions.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
ball in the
> pristine-tar branch.
You realize that pristine-tar only stores references and a small delta,
and does not store copies of the tarball, right?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-
's opinion on the desirability of an OpenSSL fork) is very
interesting. I've personally learned quite a bit from it, have now
introduced reallocarray in my own code, and am planning on introducing
strtonum.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~
wm4 writes:
> Russ Allbery wrote:
>> Note that all of the above statements also apply to libav. As near as I
>> can tell, this is not a distinguishing characteristic between the two
>> projects.
> And that's an argument against switching to FFmpeg exactly how?
I
m...@linux.it (Marco d'Itri) writes:
> And anyway I'd say that downloading the original archive is simpler than
> having to deal with pristine-tar...
I'm mystified. What is there to deal with? I literally never touch it.
It just works, completely transparently and silent
s past security track record and then *maintain* that new
level of security for some period of time.
Note that all of the above statements also apply to libav. As near as I
can tell, this is not a distinguishing characteristic between the two
projects.
--
Russ Allbery (r...@debian.org)
Cyril Brulebois writes:
> Russ Allbery (2014-08-16):
>> None of this is why libav and FFmpeg can't both be in the archive.
>> They can't both be in the archive because both the release team and
>> the security team have said that they're not interested in t
those teams.
Short of that, there's clearly a need for software of this type in Debian,
and at the same time it's clearly a ton of work. The teams involved have
indicated that they're willing (if not necessarily happy) to deal with one
version of the source base, but not two.
--
ackage are set up properly, and a moderate gain
to basing packaging on the upstream tarball as released. I also do this
for packages for which I'm upstream.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debi
ctly
how painful having all the tarballs in the revision control system is.
Never again.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
lve.
I want to be able to check out a git repository and do packaging work and
an upload, without having to pull any external artifacts from somewhere
else.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@li
sire for automatic USB disk mounting, and do
not want to be forced to install that package on my Xfce system.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
ople use systemd without being fans
of, or particularly interested in, GNOME, myself included.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe
updated, which is
daunting.
> There isn't any way to restrict which arches list arch-independent
> packages in their package lists.
That would be very nice.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-d
Cyril Brulebois writes:
> I'd therefore contact the relevant maintainers to make sure, probably
> through a bug report asking for a priority downgrade.
It looks like the only remaining purpose for gcc-4.9-base is to create the
/usr/lib/gcc//4.9.1 symlink?
--
Russ Allbery (r...
413KB
libsystemd-daemon0 39KB
so this would add about 1.5MB to essential.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listma
as the various firmware-* packages.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arch
come from FFmpeg advocates. So there's probably another side to the story
that hasn't been stated here yet.
Based purely on security evaluations by others that I was able to find on
the web, FFmpeg appears to be better at the moment than libav on the
security front (although lib
ity updates might represent more work than 100 *really*
>> minor security updates.
> How is it better to have libav, which does a lot less security
> bugfixing, in?
It's not.
However, what was proposed was having *both* of them, not dropping libav
in favor of FFmpeg.
--
Russ A
he same may apply to FFmpeg as well, but it's not a happy situation to be
in.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble?
Russ Allbery writes:
> Is upstream aware that this is a really bad track record and trying to
> do something proactive to increase the quality of the code, like
> comprehensive auditing, or proactive rewrites to use more secure coding
> practices such as some of the work that the L
able release. Maybe it's still the right thing to do, but that's a lot
of work for them.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe
pdate problem due to Oracle's very unhelpful
attitude towards security patches. And we're still talking about rather
fewer security vulnerabilities than this, I believe.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to
s of the relevant packages
taken into account.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bastian Blank writes:
> On Sun, Jul 27, 2014 at 10:45:37AM -0700, Russ Allbery wrote:
>> Bastian Blank writes:
>>> We got the advice to always use "which" with comma and "that" without
>>> comma. Especially for non-native speakers the number of
distinction has become increasingly less significant and less policed
over time, and I suspect that eventually it will wear away.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.deb
k.
It does not, at least not the way that you're calling it.
If you used --oknodo in a few places, it might be closer, but take a look
at /etc/init.d/skeleton and look at the exit status remapping that it
does.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle
ly to ensure a working cgmanager is installed?
> No, I'm not going to reupload the package to declare an incompatibility with
> a version of a dependency that was in unstable less than a day before
> getting fixed.
I concur -- not every bug is worth tightening dependencies.
--
Russ
correct exit codes.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egx9jc0h@windlord.stanford.edu
Steve Langasek writes:
> On Fri, Jul 25, 2014 at 11:42:16AM -0700, Russ Allbery wrote:
>> I continue to be baffled by people's apparent belief that this
>> happening during a major upgrade is some sort of regression. Having
>> those buttons not work after a major comp
erience.
Ah, *that's* what you're getting at. Yes, while we can argue about
severity, I agree that's a regression from the previous state of things.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ..
I continue to be baffled by people's apparent belief that this happening
during a major upgrade is some sort of regression. Having those buttons
not work after a major component upgrade, until the X session was
restarted, has been typical behavior for as long as I've been using Debian
w
roblem, we can use a more
natural packaging strategy where an upstream corresponds to a package,
without the complexity of artificial lumping together of packages that are
actually distinct.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCR
Vincent Lefevre writes:
> On 2014-07-22 19:54:10 -0700, Russ Allbery wrote:
>> logind is also not mandatory in Debian now. It's just required,
>> upstream, by all the major desktop environments.
> Not just by all the major desktop environments. It is also needed by
&
pid 1 expects users to be logged in before it
> starts the system?
No, of course not.
The tool that you're using isn't only for use during early boot, and
you're using it in a way that is incorrect for use during early boot. The
solution is to use the tool correctly.
eam,
by all the major desktop environments.
I think one point Holger was making is that *desktop environments* are not
mandatory in Debian. I have lots of Debian systems, including my desktop,
that don't run any desktop environment at all.
--
Russ Allbery (r...@debian.org) <htt
prompt.
I suspect you instead need to run systemd-ask-password with a tty. Take a
look at systemd.exec(5) at the TTY* options for the systemd unit file. I
suspect you need to write a unit file corresponding to your init script
that runs systemd-ask-password and uses TTYPath=/dev/tty1.
--
Ben Hutchings writes:
> On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote:
>> It would be nice to have a reliable kernel interface for getting
>> randomness rather than relying on proper chroot configuration.
> There is such an interface. It happens to be a char
s exhausted, and the kernel not having a reliable sysctl
> interface like OpenBSD's to get random bytes in the first place.
It would be nice to have a reliable kernel interface for getting
randomness rather than relying on proper chroot configuration. I'm not
sure sysctl should be that
worth the additional effort.
It's still more work than just merging Git branches and using
single-debian-patch, so I'm not sure if I'll ever get to the point where I
do this with all of my packages. But it has more merits than I saw
initially.
--
Russ Allbery (r...@debian.org)
r quite
a lot of small packages while not making the problem any worse than it is
today.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Con
em and the 3.0 (quilt) source format want to
control and interpret debian/patches.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact l
ey.
Ah, yes, excellent point.
So yes, other than backward compatibility, I see no reason to keep any
hash other than the hash we're also using for the GnuPG signature.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian
reSSL at the same time (the
> situation Russ Allbery described).
I'm not sure that I understand your argument. In fact, this seems like a
rather strong argument *against* using LibreSSL.
Currently, GPL software can link with BSD software without any trouble.
It can't link with OpenSSL s
ut yet). It's
basically a defense in depth argument, coupled with the argument that the
special construction of a file to create a collision for one hash function
may be incompatible with the special construction of a file required to
create a collision with the other hash function.
--
Ru
Peter Palfrader writes:
> On Mon, 14 Jul 2014, Russ Allbery wrote:
>> Using multiple hashes gives us some theoretical robustness against a
>> break in one of the hash functions provided that all clients check all
>> the hashes and the hashes would fail independently (which i
d for backward compatibility; otherwise, it's the
obvious one to drop.
If we were going to keep only one, we should keep SHA256, as that's the
most robust from a cryptographic standpoint at this point (SHA-3 may get
there, but is still too new), but obviously all the clients have to
support th
names and other obvious issues. It's not particularly hard to
turn this rune into a real script with error checking, but it would be
nice to have this functionality built into apt somehow, but to not have to
do it at the same time as the upgrade due to issues such as those on this
thread.
--
Rus
"John D. Hendrickson and Sara Darnell" writes:
> Russ Allbery wrote:
>> OpenSSL ABI implementation to another is something of an all-or-nothing
>> affair. You can do a small amount of building key packages with the
>> other
> ? rhetorically i'm unsure the
Johannes Schauer writes:
> Quoting Russ Allbery (2014-07-12 19:19:16)
>> I'd really like to see us solve this problem by figuring out a better
>> metadata distribution system (and IIRC some progress was made on that
>> front recently) than in making life more difficu
t different, as I understand it, because our
actual upstream is TeXLive, which is already doing that merging for us and
provides us with a clear upstream to use.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ..
cult for packagers.
Although if someone came up with a really elegant and scalable solution to
merging multiple upstream releases into a Debian source package, that may
work too.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to deb
is something of an all-or-nothing
affair. You can do a small amount of building key packages with the other
implementation (like we do now with libpam-heimdal and
libsasl2-modules-gssapi-heimdal), but that's both tricky and quite
limited.
--
Russ Allbery (r...@debian.org) <htt
Package: wnpp
Severity: wishlist
Owner: Russ Allbery
* Package name: libnet-duo-perl
Version : 1.00
Upstream Author : Russ Allbery
* URL : http://www.eyrie.org/~eagle/software/net-duo/
* License : Expat
Programming Lang: Perl
Description : Perl API
benefits of having that fight.
That doesn't apply in this particular case, but I think that point was
relevant to both git and node.
(I made this argument at the time, with respect to node, in the TC, so
this is probably not a new viewpoint to folks.)
--
Russ Allbery (r...@debian.org)
he investigated and confirmed that the bug
was already fixed and closed it accordingly. You have a legitimate cause
for complaint, which I think has already been heard and registered, that
the response was too terse and that you didn't realize this is what the
response meant, but the
vide that.
There's no reason to switch away from inittab for sysvinit. For systemd,
a unit file can easily do everything that you would get from inittab.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@l
mantics of inittab are quite a bit inferior to what's available with
very little additional work using the native configuration format, and the
regular inittab jobs are provided by regularly-configured services. Yes,
that is a disruptive change for people who were using initt
t.
So this is already the current state of play in Debian based on my
personal experience, and has been for quite some time.
If you haven't noticed, I suspect that you don't have as high of a
sensitivity to things breaking than you might think. Or, at least, things
you care about ha
Hat or some other company based on who they
do business with. If you feel that's an appropriate political response,
more power to you, but you are going to find it very, very hard to
entirely avoid Red-Hat-developed free software in the Linux ecosystem.
--
Russ Allbery (r...@debian.org)
struck me as so
unimportant that it wasn't worth my time to write up a bug report. I
expect to have to reboot the system cleanly after a variety of types of
upgrades (kernel upgrades, for example, obviously); a few more isn't
something I even notice.
--
Russ Allbery (r...@debian.org)
st solves a whole ton
of important problems that are quite interesting to servers.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
icense just
has crappy wording that no one reads literally. From a legal perspective,
I think one could make a pretty strong argument that estoppel applies to
any attempt to enforce the license literally at this point.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/
Thorsten Glaser writes:
> Russ Allbery wrote:
>> Thorsten Glaser writes:
>>> Yes, I fully agree. But _please_ also realise that there are people,
>>> a non-neglibile number of them, for whom these frameworks are not an
>>> improvement, and who wish to be not
be able to do, here are the situations where
you'll just need to use logind instead, and here are patches to GNOME to
make it work properly." Which is why no one's done that yet.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UN
ou've indicated that you would be happy with
them.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@l
Ctrl+Alt+Fn, press Ctrl+C and
> they're in your shell session.
This doesn't change anything else that you point out, but that's why you
run startx & and then log out of the virtual console.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/&
consists of a URL, optionally followed
by the word -b and the name of a branch in the indicated repository,
following the syntax of the git clone command. If no branch is
specified, the packaging should be on the default branch.
--
Russ Allbery (r...@debian.org) <http://www.
ore unambiguously under a good license. Maybe
someone could fork just this portion of Berkeley DB without all the
complex transaction stuff and take over upstream maintenance of just that?
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE
Luca Filipozzi writes:
> On Wed, Jun 18, 2014 at 10:05:32AM -0700, Russ Allbery wrote:
>> This is only true if the root CA is maintained with the same level of
>> security as the PGP signing key for the archive. While that's
>> something that we could probably d
to trust the PGP
signatures on the archive than to attempt to do anything with X.509. The
trust model and key management properties of X.509 are inherently inferior
for our purposes.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email t
uch as yourself is not horribly high.
(It is, however, non-zero, and I do think the US is substantially worse
than many other countries in this regard.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.o
an entropy source to reduce
the total entropy created by the the other entropy sources. The worst
they should be able to do is add zero entropy.
Cryptography Engineering has an excellent chapter on pseudorandom number
generators that gets into the issues here.
--
Russ Allbery (r...@debi
Ugh, sorry to follow up to myself, but I got a key part of this wrong.
Russ Allbery writes:
> At least based on my understanding of the theory, I think that mixing a
> backdoored entropy source with other entropy sources in a random number
> generator like Fortuna (which is based o
Gunnar Wolf writes:
> Russ Allbery dijo [Thu, Jun 12, 2014 at 07:08:40PM -0700]:
>> I would certainly hope that the mixing algorithm of any decent random
>> number source is better than just xor. And given that, I don't believe
>> the mathematics supports your assertio
fashion to allow an attacker with secret
knowledge to reproduce the number stream while still passing statistical
randomness checks, and (b) the use case for random number generators is
very narrow and this sort of backdoor won't be revealed as a bug by other
normal use.
--
Russ Allbery (r.
the fact that we have absolutely no idea what the
hardware random number generator is doing, it would be quite possible to
insert a mathematical back door into it, and there's no way to audit it, I
understand why people want to put a software randomization layer that we
*can* audit in front of it.
Kurt Roeckx writes:
> On Sun, Jun 01, 2014 at 11:39:34AM -0700, Russ Allbery wrote:
>> Build-Depends on perl (>= 5.20) would make the transition smooth for
>> users and the buildds. The only drawback I can think of is that you'd
>> have to revert that and the
stead.
> How can we make the transition smooth ?
> I have a package.install file that contains a line
> /usr/lib/perl5/
Build-Depends on perl (>= 5.20) would make the transition smooth for users
and the buildds. The only drawback I can think of is that you'd have to
revert
t know if that's now been fixed
in GCC, but that's probably much of the historical reason.
My impression is that most people using GCC use -O2, so it's the
best-tested path.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, em
This is a fantastic project update. I admire the work that
both went into all the porting that you've accomplished and into producing
such a nice summary for the rest of the project. Thank you!
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To U
Arto Jantunen writes:
> Because a package that doesn't work at all (and thus breaks rdeps) isn't
> as broken as a package that wipes the root fs on installation.
Note that the latter breaks the whole system, and hence is critical
regardless of this distinction.
--
901 - 1000 of 3430 matches
Mail list logo
