On 2013-07-04 09:23:49 +0200, Stefano Zacchiroli wrote:
I'm curious, can you elaborate on why as upstream you'd refuse to add
something like a protocol command that return a URL pointing to a
tarball containing the source code of the INN version the users are
running? At times, I'm really
On 2013-07-04 15:00:05 +0200, Stefano Zacchiroli wrote:
On Thu, Jul 04, 2013 at 02:08:33PM +0200, Vincent Lefevre wrote:
What about users who patch and rebuild software locally?
That was the second paragraph of my post (that you snipped :)), i.e.:
I mean, sure, it *is* more tricky
On 2013-07-10 13:06:47 +0200, Stefano Zacchiroli wrote:
If you modify the software you might get in trouble but, according to my
personal ethics, that's the trouble you should have. However, please
note that as long as you run the software only for yourself, you don't
have any problem. You
On 2013-07-11 13:41:47 +, Jeremy T. Bouse wrote:
My understanding though that if Debian is the one making the modification
then Debian is the one responsible for making the source available. If the
end user is then modifying the source then they would subsequently need to
make those
On 2013-07-31 15:46:29 +0800, Thomas Goirand wrote:
On 07/31/2013 08:30 AM, Steve Langasek wrote:
What I'm missing your email is a problem statement explaining what it is
you're trying to solve. The current implementation has been working
reliably for years.
He did wrote it. 127.0.1.1
On 2013-07-31 11:00:24 +0200, Vincent Bernat wrote:
❦ 31 juillet 2013 09:46 CEST, Thomas Goirand z...@debian.org :
He did wrote it. 127.0.1.1 breaks because some daemon (many, according
to him) bind only on 127.0.0.1, and not 127.0.0.0/8 as they should.
How a daemon could bind to
On 2013-07-31 21:01:21 +0800, Thomas Goirand wrote:
On 07/31/2013 06:47 PM, Vincent Lefevre wrote:
But this wouldn't necessarily solve the mentioned problem
anyway.
I'm not sure there's a problem anyway. I'm on the side of Steve, which
is I think the current setup works quite well.
I
On 2013-08-12 02:51:52 +0200, Adam Borowski wrote:
Detecting non-UTF files is easy:
* false positives are impossible
* false negatives are extremely unlikely: combinations of letters that would
happen to match a valid utf character don't happen naturally, and even if
they did, every
On 2013-08-12 15:16:59 +0200, Adam Borowski wrote:
On Mon, Aug 12, 2013 at 12:50:35PM +0200, Vincent Lefevre wrote:
On 2013-08-12 02:51:52 +0200, Adam Borowski wrote:
Detecting non-UTF files is easy:
* false positives are impossible
* false negatives are extremely unlikely
On 2013-08-12 17:58:20 +0200, Adam Borowski wrote:
On Mon, Aug 12, 2013 at 03:50:19PM +0200, Florian Lohoff wrote:
5. All programs consuning UTF8 Text must understand a BOM.
I'm afraid I don't agree here: BOMs are nasty stuff that serve no purpose
once you standardize on UTF8. They might
On 2013-08-12 20:14:30 +0100, Dmitrijs Ledkovs wrote:
What about locales though?
* C.utf8 locale should be always available
* C.utf8 locale should be the default/fallback locale
* utf8 locale variants should be default / available / preferred
(where appropriate)
If scripts intend to use
On 2013-08-13 10:25:31 +, Thorsten Glaser wrote:
Vincent Lefevre vincent at vinc17.net writes:
If scripts intend to use LC_ALL=C.UTF-8 to force everything to
the standard locale with UTF-8 support, then the glibc should
be modified to regard C.UTF-8 like C w.r.t. $LANGUAGE. I mean
On 2013-10-02 16:51:09 +0200, Dominik George wrote:
Dominique Dumont d...@debian.org schrieb:
well, you proposed a version like 'hg'. if upstream switches to
git, you can't use a version like 'git' because it sorts before
hg. I grant you that is easy to work around.
If you deem it
On 2013-10-02 17:50:40 +0200, Dominik George wrote:
I established an advantage for the user using my proposal - go get
me a disadvantage for the packager.
As a user, I dislike long version strings.
That said, what's the point in NOT being verbose?
Version strings need to be displayed, and if
On 2013-10-04 13:40:29 +0200, Dominik George wrote:
My argument for keeping the VCS hash is to ease identifying the code
in the package.
Does it need to be in the version string?
Why not somewhere else?
The goal of the Version field in Debian packages is to identify
and sort several versions
I'm replying to an old message, but...
On 2013-10-23 23:06:39 +0200, John Paul Adrian Glaubitz wrote:
On 10/23/2013 10:30 PM, Christoph Anton Mitterer wrote:
Of course I can install the package but don't have to switch init= to
it, nevertheless it seems that already this alone adds several
On 2013-12-21 18:04:19 -0800, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
I've spent several hours to find what was wrong with lightdm, and
eventually found the culprit earlier today: just the fact that the
systemd package was installed! So, yes, systemd currently breaks
On 2013-12-22 09:31:09 -0800, Russ Allbery wrote:
Milan P. Stanic m...@arvanta.net writes:
Really odd. With my testing/unstable installation on amd64 and armhf
(Asus TF101 tablet) systemd and lightdm combo works without any problem
for nearly a year.
It's possible I had some local
On 2013-12-28 09:45:09 +0100, David Weinehall wrote:
Relicensing libraries that have long been GPL v2 (or later) or LGPL v2.1
(or later) to (L)GPL v3 (or later) is, if anything, very antisocial,
since it locks out users of GPL v2 (only) software and forces the GPL v3
interpretation onto GPL v2
On 2013-12-28 17:59:35 -0500, Stephen M. Webb wrote:
On 12/28/2013 04:15 PM, Kurt Roeckx wrote:
On Sat, Dec 28, 2013 at 04:11:18PM -0500, Stephen M. Webb wrote:
There are organization who will allow v2 but not v3 because of
the tivoizaton and patent clauses. A developer may want his work
On 2013-12-28 19:24:33 -0800, Steve Langasek wrote:
Now, the companies in question may legitimately regard a GPLv2+
upstream as a source business risk, because they have no guarantee
that future versions of the software won't be made available under
GPLv3+ instead of GPLv2+, and if they're
On 2013-12-30 10:57:32 -0800, Russ Allbery wrote:
Most upstream authors that I've spoken with don't believe that licensing
crosses the shared library ABI boundary, that the shared OpenSSL library
and the GPLv2 program that calls it remain separate works, and therefore
there is no need for
On 2014-01-13 10:43:50 -0800, Russ Allbery wrote:
While someone could fix the package, you may want to consider not doing
so. After running into endless bugs in xpdf, I personally switched to
mupdf for a light-weight PDF reader and found it superior in every respect
except for the fact that
On 2014-02-06 13:44:30 +, Felipe Sateler wrote:
On Thu, 06 Feb 2014 00:47:54 +0100, Julian Taylor wrote:
On 06.02.2014 00:39, Jaromír Mikeš wrote:
-ffast-math
this is dangerous it changes results, sometimes significantly (e.g. for
complex numbers), only use if you don't care about
On 2014-04-10 11:48:44 +, Thorsten Glaser wrote:
Ian Jackson dixit:
If the architecture uses two's complement, however, then the code is
correct.
Unfortunately adversarial optimisation by modern compilers means that
this kind of reasoning is no longer valid.
The compiler might
On 2014-04-10 14:38:46 -0700, Russ Allbery wrote:
I don't want, necessarily, to have slower code to make handling
corner cases easier. However, I am generally happy to have slower
code in return for making the system more secure, as long as the
speed hit isn't too substantial. Security is a
On 2014-04-12 20:32:33 -0700, Russ Allbery wrote:
I enabled -fstrict-overflow -Wstrict-overflow=5 -Werror in my standard
[...]
GCC does silly things with -Wstrict-overflow=5.
For instance, consider the following code:
int foo (int d)
{
int m;
m = d * 64;
return m;
}
With gcc -O2
On 2014-04-14 13:11:12 +0200, Jakub Wilk wrote:
* Vincent Lefevre vinc...@vinc17.net, 2014-04-14, 12:56:
IMHO, in general, for security, it is better to run code with a sanitizer
(such as clang -fsanitize=undefined -fno-sanitize-recover, assuming that
the code does not use floating point
On 2014-04-14 14:14:14 +0200, Raphael Geissert wrote:
Vincent Lefevre wrote:
[...]
int foo (int d)
{
int m;
m = d * 64;
return m;
}
[...]
while the cause of a potential bug would be the same. For consistency,
GCC should have warned for the first code too
On 2014-04-14 17:01:42 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
But what I mean is that it's pointless to emit such a warning when the
effect of the potential integer overflow is already visible, for
instance in printf below:
m = d * C;
printf (%d\n, m
On 2014-04-15 10:17:04 -0700, Russ Allbery wrote:
Vincent Lefevre vinc...@vinc17.net writes:
Andrew Pinski said: For the first warning, even though the warning is
correct, I don't think we should warn here as the expressions are split
between two different statements., which is more or less
On 2014-04-15 21:57:21 +0100, Roger Lynn wrote:
The purpose of this gcc warning isn't to warn you that overflow
might happen, but to warn you when gcc's optimisations have broken
any two's complement overflow behaviour that you might have
expected. Thus if you have written code that assumes
On 2014-04-24 22:04:40 +0300, Shachar Shemesh wrote:
Following the discussion from a few days ago about Cava (C like language
with no undefined behavior), gcc 4.9 is now out[1]. One of the changes
there is a runtime check for undefined behavior. Just compile with
-fsanitize=undefined, and your
On 2014-04-28 16:45:56 +, Thorsten Glaser wrote:
Shachar Shemesh shachar at debian.org writes:
the changes there is a runtime check for undefined behavior. Just
compile with -fsanitize=undefined, and your program will crash with
log if it performs an operation that C/C++
I could see in a mail from control@b.d.o:
[...]
After four attempts, the following changes were unable to be made:
fixed_versions of #731426 is 'systemd/204-9' not '204-9'
fixed_versions of #726763 is 'systemd/204-9' not '204-9'
Failed to forcibly merge 729576: Unable to modify bugs so they could
On 2014-06-17 13:20:59 +0100, Simon McVittie wrote:
It should be possible to make a CA certificate that is only considered
to be valid for the spi-inc.org and debian.org subtrees, and then trust
the assertion that SPI control that certificate - but in widely-used
applications, that isn't
On 2014-06-18 14:20:10 +1000, Russell Stuart wrote:
So you need X.509 PKI (even with all its flaws) during that first
contact. But after you've sent them money or downloaded their software
you have formed a trust relationship with whoever controls that cert far
stronger than the assurances
The Debian Policy Manual on
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
says:
12.5 Copyright information
[...]
In addition, the copyright file must say where the upstream sources
(if any) were obtained, and should name the original authors.
But I wonder
On 2014-07-13 13:17:24 +0200, Arno Töll wrote:
Unfortunately it turns out, that /a lot/ of people use aptitude
--purge-unused safe-upgrade, or the apt equivalent apt-get
dist-upgrade --purge which causes dpkg to purge the user's
configuration, in particular enabled modules, during the upgrade
On 2014-07-14 08:53:22 +, Thorsten Glaser wrote:
But I normally use apt-get --purge dist-upgrade both to upgrade
across distros and to stay within one distro (or sid), because
otherwise I get issues:
* Running upgrade before dist-upgrade sometimes doesn't get the
dependencies right
On 2014-07-16 13:46:12 +0200, Guillem Jover wrote:
On Wed, 2014-07-16 at 11:41:25 +0200, Vincent Lefevre wrote:
On 2014-07-13 13:17:24 +0200, Arno Töll wrote:
Unfortunately it turns out, that /a lot/ of people use aptitude
--purge-unused safe-upgrade, or the apt equivalent apt-get
dist
On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote:
On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote:
I do that too. I haven't seen any official documentation saying that
this is a bad thing to do.
aptitude actively warns against it as highlighted in this thread.
Wrong
On 2014-07-17 03:21:28 +0200, Christian Hofstaedtler wrote:
* Arno Töll a...@debian.org [140713 13:25]:
* Ignore the problem, and refer to the manpage of aptitude without
proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO
NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING.
On 2014-07-17 15:44:18 +0200, Arno Töll wrote:
On 17.07.2014 15:38, Christian Hofstaedtler wrote:
My understanding was that the new apache binaries would install new
config files, and it would then work? (With the correct
replaces/breaks/...)
Yes. However, Apache has a notable number of
On 2014-07-18 00:32:25 +0300, Andrei POPESCU wrote:
On Jo, 17 iul 14, 03:17:35, Vincent Lefevre wrote:
On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote:
On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote:
I do that too. I haven't seen any official documentation saying
On 2014-07-22 22:10:07 +0200, Arno Töll wrote:
On 21.07.2014 20:58, Vincent Lefevre wrote:
Yes, and a consequence of this loss is that dpkg fails.
dpkg does not at all fail. If anything dpkg errors out because Apache's
maintainer script failed, because invoke.rc-d apache2 restart failed
On 2014-07-23 01:19:01 +0200, Christian Hofstaedtler wrote:
* Arno Töll a...@debian.org [140722 22:10]:
On 21.07.2014 20:58, Vincent Lefevre wrote:
Yes, and a consequence of this loss is that dpkg fails.
dpkg does not at all fail. If anything dpkg errors out because Apache's
On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
I just tried updating testing on my system. I currently use
sysvinit-core (reasons below), but aptitude is telling me that I
should remove this in favour of systemd-sysv. Hmm, why is that?
Well, because the new version of libpam-systemd,
On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:
On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
I just tried updating testing on my system. I currently use
sysvinit-core (reasons below), but aptitude is telling me that I
should remove this in favour of systemd-sysv. Hmm, why
On 2014-07-23 02:05:26 +0200, Arno Töll wrote:
On 23.07.2014 01:19, Vincent Lefevre wrote:
BTW, I'm wondering whether the fact that invoke.rc-d apache2 restart
fails should make the postinst script fail and affect the whole upgrade.
It does actually as we fixed #716921 a while back.
OK, I
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 hplip via dependencies[*], which is quite surprising for a
HP
On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.
Screen sessions, SSH sessions and computation processes running in
background are lost after a
On 2014-07-25 23:04:55 +0200, Michael Biebl wrote:
Am 25.07.2014 22:43, schrieb Vincent Lefevre:
On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users
On 2014-07-27 11:39:58 +0200, Bastian Blank wrote:
On Sun, Jul 27, 2014 at 06:57:24PM +1200, Chris Bannister wrote:
Presume you mean ... scheduler that handles ...
It may even be proper English to say ... scheduler which handles ...
We got the advice to always use which with comma and that
On 2014-08-09 18:26:19 +0100, Kieran Kunhya wrote:
We also use a fork specifically to work around very wasteful
calculations in libswscale during 10-bit chroma conversion that
involve multiplying a pixel by a 2^n value with 32-bit precision and
then shifting that value down by n back to 16-bit
On 2014-09-26 09:19:17 +0200, Samuel Thibault wrote:
Nikolaus Rath, le Thu 25 Sep 2014 17:26:40 -0700, a écrit :
Wasn't there some web server that used to put query script variables
into the environment of the CGI script?
Well, that ought to have been fixed a long time ago already,
On 2014-09-26 10:33:20 +0200, Josselin Mouette wrote:
Brian May br...@microcomaustralia.com.au wrote:
No, I don't think that is the case. I believe sudo interprets
those assignments itself (as also shown in man page), and the
error I got clearly shows this to be the
On 2014-09-27 11:18:18 +0100, Jonathan Dowland wrote:
On 27 Sep 2014, at 10:36, Adam Borowski kilob...@angband.pl wrote:
Except that the endianness war has been won by little-endian
And yet, network byte order remains big.
But does this matter in the context of these binary data files?
On 2015-01-22 12:41:05 +1000, Russell Stuart wrote:
On Wed, 2015-01-21 at 21:10 -0500, Michael Gilbert wrote:
So anyway, nn-subscribe can be used to spam confirmation messages
currently, and general mail to the bts from an unknown address will
end up doing the same, but it's basically a
On 2015-01-18 16:06:32 -0800, Don Armstrong wrote:
I'm going to put together a bit more firm of a proposal in the next few
weeks, but I think that basically everything but nnn-done@ and
nnn-submitter@ should be no different from mailing nnn@, and until I
allow submitters to opt out of e-mail,
On 2015-01-20 11:59:45 +0100, Thorsten Glaser wrote:
On Thu, 15 Jan 2015, Vincent Lefevre wrote:
I don't even see how it can work. Perhaps you need to explain.
*sigh*…
• Take output of 「apt-cache show texlive-latex-extra」
• Replace all newlines with \x01
• Replace all “\x01\x20
On 2015-01-13 10:22:47 +0100, Thorsten Glaser wrote:
On Mon, 12 Jan 2015, Vincent Lefevre wrote:
which doesn't work at all, neither with zsh nor with bash.
It works with mksh, GNU bash, ATT ksh93, zsh (Debian sid).
I don’t see why it shouldn’t work on older versions either.
It didn't work
On 2015-01-15 14:00:21 +0100, Thorsten Glaser wrote:
On Wed, 14 Jan 2015, Vincent Lefevre wrote:
which doesn't work at all, neither with zsh nor with bash.
It works with mksh, GNU bash, ATT ksh93, zsh (Debian sid).
I don’t see why it shouldn’t work on older versions either
On 2015-01-24 02:00:34 +, Ben Hutchings wrote:
On Wed, 2015-01-21 at 17:07 +1300, Chris Bannister wrote:
Or an option in reportbug to do so, turned on by default. It could put
an X- header in the email.
That way users of reportbug can choose to be 'spammed' or not.
This is still
On 2015-01-10 10:50:58 +1100, Riley Baird wrote:
True. I honestly think that this is such an insignificant problem that
updating the sed or perl script every so often wouldn't be that much of
a problem.
But this may yield bug reports, which annoy the developers.
--
Vincent Lefèvre
On 2015-01-10 13:34:37 +0100, Thorsten Glaser wrote:
Nonsense, the format is trivial and stable.
I've never seen that it was stable.
A quick one-line-ish fix for this (requires a modern shell) is:
apt-cache show texlive-latex-extra | tr '\n' $'\001' | sed $'s/\001 / /g' |
tr $'\001' '\n'
On 2015-01-10 17:27:39 +0100, Guillem Jover wrote:
I also think it would be best to switch that Description to use list
syntax. Daniel Burrows prepared a policy proposal some time ago, and
did some analysis:
https://wiki.debian.org/Aptitude%3A%3AParse-Description-Bullets%3Dtrue
the
On 2015-01-09 16:02:52 +, Ian Jackson wrote:
Vincent, perhaps you would care to file a bug with a patch which
reduces the description to a plausible size ?
I reported
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774942
but the maintainer disagrees.
--
Vincent Lefèvre
On 2015-01-10 07:05:48 +1100, Riley Baird wrote:
Otherwise shouldn't utilities (such as dpkg -s) provide a
configurable way to limit the output of the Description: field?
You can pipe the output to head or tail to sort of achieve what you
want to.
Obviously not. It may be possible with
On 2015-01-10 05:03:56 +0900, Norbert Preining wrote:
Hi everyone,
(I am not subscribed to Cc, due to obvious reasons, so please Cc
me any further *relevant* remarks - I don't care for the rants)
concerning Vincent's email: he mentioned that:
but the maintainer disagrees.
but he did not
Some texlive-* packages (and perhaps others) have a huge extended
description, e.g. more than 1900 lines for texlive-latex-extra!
Shouldn't the length be limited by the Debian policy?
Otherwise shouldn't utilities (such as dpkg -s) provide a
configurable way to limit the output of the
On 2015-01-13 01:42:57 +1300, Chris Bannister wrote:
On Mon, Jan 12, 2015 at 01:24:20PM +0100, Vincent Lefevre wrote:
On 2015-01-10 13:34:37 +0100, Thorsten Glaser wrote:
Nonsense, the format is trivial and stable.
I've never seen that it was stable.
A quick one-line-ish fix
On 2015-01-09 14:56:14 -0800, Don Armstrong wrote:
On Fri, 09 Jan 2015, Vincent Lefevre wrote:
The blank lines are not the only problem. Removing them would be a big
step forward, but the description would actually still be much too
long (more than 900 lines).
Lines aren't really
On 2015-04-19 11:43:09 +0300, Niko Tyni wrote:
Cons:
E increased memory usage on systems running multiple perl processes
I suppose that this concerns only the case where one has /usr/bin/perl
processes *and* some other processes that use libperl, and at most
this doubles the memory used by
On 2015-04-20 21:32:17 +0300, Niko Tyni wrote:
On Sun, Apr 19, 2015 at 02:25:55PM +0200, Axel Beckert wrote:
* by providing two conflicting packages perl-base and
perl-base-static.
dpkg cries loudly (and rightly so) if you try to remove an Essential:yes
package like perl-base.
Couldn't
On 2015-05-06 12:21:14 +0200, Ansgar Burchardt wrote:
On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
cron is part of POSIX.
The problem here is what the expectations of an experienced UNIX person
are... I hopefully count as having some experience, but I don't expect
cron to be available
On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote:
dpkg --purge \
discover discover-data libdiscover2 installation-report laptop-detect \
nano tasksel tasksel-data task-english acpi acpid acpi-support-base \
isc-dhcp-client isc-dhcp-common eject \
nfacct libmnl0 libnetfilter-acct1
On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote:
On May 05, Ansgar Burchardt ans...@debian.org wrote:
- nfacct:
No idea why this is at Priority: important.
- demote to optional
Even extra... This is a very niche package and I have no idea why it is
being installed
On 2015-05-06 15:23:58 +0100, Neil Williams wrote:
So, no, there isn't something broken - the uploader needs to file the
bug as set out in the developer reference.
Thanks for the information. To make sure that it is done and since
bugs.debian.org didn't show any such bug, I've just filed such a
On 2015-05-12 22:31:43 +0200, Marc Haber wrote:
On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre
vinc...@vinc17.net wrote:
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP
On 2015-05-11 18:04:14 +0200, Marc Haber wrote:
In IPv6, routers advertise prefixes. If a new prefix comes, end
systems configured for SLAAC will allocate an IP address in this
prefix and begin to use it.
On this subject, end systems under Debian are configured for SLAAC
by default. :-(
--
On 2015-06-15 05:04:46 +0200, Guillem Jover wrote:
On Sun, 2015-06-14 at 16:48:21 +0200, Vincent Lefevre wrote:
(this example is a postfix mail log) and uses much less memory for
compression:
$ sh -c 'ulimit -v 20; lzip -9 mail.log /dev/null'
$ sh -c 'ulimit -v 80; xz -9
On 2015-06-15 18:56:47 +0200, Andreas Metzler wrote:
Vincent Lefevre vinc...@vinc17.net wrote:
[...]
(Bug 788710 shouldn't have been closed, but changed to something
like what bug 788735 says.)
[...]
No, it should not have been filed, since the same bug had been filed 5
times
On 2015-06-15 20:52:25 +0200, Magnus Holmgren wrote:
But libgnutls-deb0-28 technically doesn't break libnettle4, nor does
libnettle6. It's only certain combinations of three or more packages
that are broken, something the dependency system can't handle.
Then either the dependency system should
Normally, a well-designed dependency system should make sure that the
user cannot install an incorrect combination of packages (avoiding
segmentation faults and internal errors), e.g. during a partial
upgrade. But it appears that this is not the case, and users are
required to do apt-get
On 2015-06-14 18:15:33 +0200, Dominik George wrote:
Hi,
Note that the problem still occurs on an available set of packages:
just start with a Debian/stable system (jessie) and upgrade
libgnutls-deb0-28 to unstable (no dependencies/conflicts will
yield an upgrade of wget, which will
I'm currently using xz for my own files, but...
On 2015-06-14 05:46:00 +0200, Guillem Jover wrote:
On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
On 06/13/2015 10:55 AM, Paul Wise wrote:
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
As a friend puts it:
This
On 2015-06-16 09:12:36 -0700, Russ Allbery wrote:
There are a lot of really complex things you can do with versioning and
cases where that version number is meaningful, but for the vast majority
of libraries, I recommend not worrying about it and just always using some
simple transform of the
On 2015-06-14 18:43:33 +0200, Marc Haber wrote:
On Sun, 14 Jun 2015 16:03:32 +0200, Vincent Lefevre
vinc...@vinc17.net wrote:
Normally, a well-designed dependency system should make sure that the
user cannot install an incorrect combination of packages (avoiding
segmentation faults
On 2015-07-29 00:21:54 +0200, Antonio Diaz Diaz wrote:
A compressed file is like an envelope with a message inside. The objective
of the decompressor is to extract the message and deliver it intact to the
user.
The problem is that data could have been appended to a compressed file
(thanks
On 2015-08-02 11:45:38 -0700, Russ Allbery wrote:
There were a few long messages to this thread that I didn't absorb in
their entirety, so apologies if this is a repeat. But another angle of
this is that the discussion is about using lzip *for Debian packages*. In
that context, being
On 2015-08-08 20:58:37 +0200, Daniel Pocock wrote:
So, is there any strategy for HiDPI with Debian? Is a BTS tag needed to
track such issues perhaps? Or is it already dealt with in unstable and
people just have to wait for it?
I have similar problems with a 3200x1800 15 screen. Here's my
On 2015-08-07 15:54:26 +0200, Antonio Diaz Diaz wrote:
I have no experience at all rigging tarballs, but it took me just
minutes to obtain two xz compressed tarballs with very different
contents that match in size and sum(1). I did it just with an
editor, ddrescue and data from /dev/urandom,
On 2015-08-07 21:27:03 +0200, Vincent Lefevre wrote:
On 2015-08-07 15:54:26 +0200, Antonio Diaz Diaz wrote:
I have no experience at all rigging tarballs, but it took me just
minutes to obtain two xz compressed tarballs with very different
contents that match in size and sum(1). I did
On 2015-08-09 18:02:05 +0200, Vincent Bernat wrote:
While it is possible to derive the true DPI setting from the resolution
and the dimension, I don't think that's what users would be
expecting. On a laptop, you'll want smaller fonts than on a desktop
because the screen is usually nearer from
On 2015-07-26 14:10:10 +0200, Antonio Diaz Diaz wrote:
Guillem Jover wrote:
TBH this smells like FUD. For example I've never heard of corruption in
.xz files due to non-robustness, I'd expect that corruption to come from
external forces, and that integrity would help or not detect it.
Sure
The gstreamer1.0-plugins-bad package description says:
[...]
GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared
to the rest. They might be close to being good quality, but they're missing
something - be it a good code review, some documentation, a set of tests, a
real
On 2015-09-03 10:26:25 +0200, Fabian Greffrath wrote:
> Hi Vincent,
>
> > which is unacceptable from a security and stability point of view.
>
> do you conclude this from the package description?
and information from upstream. Thus I don't want to be forced to
use plug-ins I don't need.
--
On 2015-09-13 23:57:13 +0200, Paul Wise wrote:
> This config option improves the aptitude resolver for some situations:
>
> /etc/apt/apt.conf.d/99aptitude-resolver:
> Aptitude::ProblemResolver { SolutionCost "removals"; }
Unfortunately this has the consequence that aptitude sometimes wants
to
On 2016-01-03 16:54:40 +1100, Brian May wrote:
> The package called "unison2.40.102" version 2.40.102-3+b1 in testing and
> unstable is broken. This broken package is not in stable. If it can't
> get fixed, it probably should get removed.
Yes, I think that it should be removed ASAP. Thus, users
201 - 300 of 399 matches
Mail list logo
