Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-02 21:53:08 +0200, Philipp Kern wrote: > Vincent, > > am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben: > > I don't think that the status even of a big package like iceweasel > > is satisfactory. > > I pretty much agree. But what's the problem here? That xulrunner

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-02 09:48:34 -0700, Russ Allbery wrote: > Vincent Lefevre writes: > > On 2013-04-02 14:29:46 +0100, Neil Williams wrote: > > >> That is not how it actually works out. Policy changes are made which > >> require old packages to build with new flags, compile

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: > Just to expand slightly on this, the problem you're both poking at is > that during a freeze, our incentives are directed towards fixing RC bugs > (because then we can release, which means we can then do what we prefer > to, which (as you can s

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-03 20:14:32 +0200, Philipp Kern wrote: > On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote: > > In general, bug-fix releases (which are also blocked by the freeze) > > don't introduce new bugs. > > Case in point: > http://www.h-online.com/op

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-03 20:17:47 +0200, Philipp Kern wrote: > On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote: > > > I pretty much agree. But what's the problem here? That xulrunner and > > > iceweasel have rdeps in the archive that aren't necessarily > &g

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-04 16:23:33 +0200, Philipp Kern wrote: > On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote: > > It seems that most reverse dependencies for iceweasel are l10n > > packages and extensions, so that one can consider them as part > > of the upgrade. The r

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-04 21:08:45 +0200, Philipp Kern wrote: > On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote: > > I wonder whether there are packaged extensions […] > > So you didn't actually look. EOT from me, it's wasting my time. Sorry, I meant "why"

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-15 15:31:38 +0100, Neil McGovern wrote: > On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote: > > So, transitions could be avoided in a social way. No need for a freeze. > > Let's see how well that works - look at the very first message in this > th

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On 2013-04-23 14:23:57 +0200, Goswin von Brederlow wrote: > On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote: > > On 2013-04-18, Goswin von Brederlow wrote: > > >> Oh, that's a good point. Yes, I hadn't thought about that specific case > > >> for testing ABI breakage in experimental.

Re: jessie release goals

On 2013-05-07 00:52:03 +0800, Thomas Goirand wrote: > On 05/06/2013 10:08 PM, Christoph Anton Mitterer wrote: > > The usually come only with a default config which may not be hardened > > enough for the local system, and that short time may already be enough > > for an attacker to attack. > If the

Re: jessie release goals

On 2013-05-06 17:22:57 +0200, Marco d'Itri wrote: > On May 06, Christoph Anton Mitterer wrote: > > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per > > default on the network (unless loopback only) shouldn't be started per > > default, after being installed. > This has been

Re: epoch fix?

On 2013-05-09 00:25:06 +0200, Jakub Wilk wrote: > Let me try to explain where the difference lies. Consider the following > sequences of uploads: > > foo_4 > foo_5 > foo_1:4 > foo_1:6 > > bar_4 > bar_5 > bar_5really4 > bar_6 > > Two kind of "bugs" in (build-)dependencies on these packages could

Re: wheezy postmortem re rc bugfixing

On 2013-05-10 14:57:46 +0200, Piotr Ożarowski wrote: > [Charles Plessy, 2013-05-09] > > For a large number of packages if not all, we should allow the > > package maintainers to manually migrate their packages to Testing during the > > Freeze, within boundaries set on debian-devel-announc

Re: epoch fix?

On 2013-05-10 02:01:15 +0800, Thomas Goirand wrote: > Seems nobody is picking-up on the topic, so I'll try > once more, because I'm convince there's something > we could do here. How about replacing epoch separator > char : by @ in the filenames for example? Why not keep the usual : escaping as in

Re: jessie release goals

On 2013-05-07 23:53:07 +0800, Thomas Goirand wrote: > On 05/07/2013 04:11 AM, Vincent Lefevre wrote: > > This doesn't make any sense. What is installed is a package, not > > a service. There are packages, like rsync, that provide more than > > a service, e.g. a client

Re: jessie release goals

On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: > ]] Vincent Lefevre > > > I agree for these services (though Apache is useless after just > > being installed, as one just has a dummy web page). > > So useful, since you can then put files into the docroot and serve

Re: jessie release goals

On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote: > On 05/07/2013 04:00 AM, Vincent Lefevre wrote: > > This can be fine for some daemons/servers. For instance, for a web > > server, displaying a default web page is harmless. But what about a > > mail server? Any default

Re: jessie release goals

On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote: > ]] Vincent Lefevre > > > On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: > > > ]] Vincent Lefevre > > > > But not for postfix, which can reject mail by default without an > > > > initial conf

Re: jessie release goals

On 2013-05-13 12:02:31 +0100, Philip Hands wrote: > Vincent Lefevre writes: > > My only use of Apache on some machine is because of sensord. But > > it may happen that in a few months, I would no longer need sensord > > and may remove the package. In this case, it would make

Re: jessie release goals

On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote: > ]] Vincent Lefevre > > > On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote: > > > So you configured it through debconf, in a non-default way, and it > > > refused mails according to how you configured it.

Re: jessie release goals

On 2013-05-13 08:48:33 -0400, The Wanderer wrote: > On 05/13/2013 08:33 AM, Tollef Fog Heen wrote: > > >]] Vincent Lefevre > > > >>On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote: > > >>>No, it does not, since the default configuration («Local

Re: jessie release goals

On 2013-05-13 14:37:28 +0100, Philip Hands wrote: > Vincent Lefevre writes: > > There's also a problem that the man pages are in the package: > > > > $ dpkg -L apache2.2-common | grep /man/ > > /usr/share/man/man8 > > /usr/share/man/man8/apache2.8.gz > >

Re: systemd effectively mandatory now due to GNOME

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 sever

Re: systemd effectively mandatory now due to GNOME

On 2013-12-21 18:04:19 -0800, Russ Allbery wrote: > Vincent Lefevre 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, syste

Re: systemd effectively mandatory now due to GNOME

On 2013-12-22 09:31:09 -0800, Russ Allbery wrote: > "Milan P. Stanic" 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 configuratio

Re: GnuTLS in Debian

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

Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]

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

Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]

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

Re: GnuTLS in Debian

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 O

mupdf (was: xpdf removed from testing?)

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 tha

Re: amd64 arch and optimization flags?

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

Re: Having fun with the following C code (UB)

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

Re: Having fun with the following C code (UB)

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

Re: Having fun with the following C code (UB)

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 -fstri

Re: Having fun with the following C code (UB)

On 2014-04-14 13:11:12 +0200, Jakub Wilk wrote: > * Vincent Lefevre , 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 us

Re: Having fun with the following C code (UB)

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

Re: Having fun with the following C code (UB)

On 2014-04-14 17:01:42 -0700, Russ Allbery wrote: > Vincent Lefevre 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: > > >

Re: Having fun with the following C code (UB)

On 2014-04-15 10:17:04 -0700, Russ Allbery wrote: > Vincent Lefevre 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.&q

Re: Having fun with the following C code (UB)

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

Re: Gcc and undefined behavior

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 y

Re: Gcc and undefined behavior

On 2014-04-28 16:45:56 +, Thorsten Glaser wrote: > Shachar Shemesh 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++ con

fixed_versions format in the BTS and forcemerge

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

Bug#619520: linux-image-2.6.37-2-amd64: some Ethernet cables are not detected

On 2011-03-25 01:15:54 +0100, Vincent Lefevre wrote: > > It is your responsibility to set an appropriate time limit for > > guessnet. > > This doesn't solve the problem: it makes the boot longer. By longer and unreliable. The 4-second maximum delay is still not suffi

Re: Processed: Re: Processed: reassign 619520 to general

reassign 619520 ethtool severity 619520 normal thanks On 2011-03-25 09:18:04 +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > reassign 619520 guessnet > Bug #619520 [general] eth0 is not activated early enough, causing a delay in > the Ethernet de

Re: Back to technical discussion? Yes! (was: network-manager as default? No!)

On 2011-04-04 17:31:18 +0400, Stanislav Maslovski wrote: > On Mon, Apr 04, 2011 at 05:35:10PM +0530, Josselin Mouette wrote: > > It seems to be a common belief between some developers that users should > > have to read dozens of pages of documentation before attempting to do > > anything. > > > >

Re: Back to technical discussion? Yes! (was: network-manager as default? No!)

Hi, On 2011-04-05 20:37:39 +0300, Andrew O. Shadoura wrote: > Hello, > > On Tue, 5 Apr 2011 14:31:40 +0200 > Vincent Lefevre wrote: > > > [About the general problem of documentation] > > The problem is to find the correct tools and the correct > > documen

Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

On 2011-04-06 11:22:07 +0100, Simon McVittie wrote: > Not everything in /etc/shells is POSIXy enough to be /bin/sh. The > *csh family aren't Bourne shells, and while zsh is a very nice > Bourne-ish interactive shell, in its default configuration it isn't > POSIX-compliant. When invoked as sh, zsh

Re: Back to technical discussion? Yes! (was: network-manager as default? No!)

On 2011-04-06 07:24:30 +0200, Josselin Mouette wrote: > There are several hacks to do that (like guessnet or laptop-net), but I > don’t think this can work correctly in the general case with IPv4. FYI, I had used laptop-net in the past, but it has been removed from Debian: http://bugs.debian.or

Re: Back to technical discussion? Yes! (was: network-manager as default? No!)

On 2011-04-06 18:26:45 +0300, Andrew O. Shadoura wrote: > If you do `ifdown`, either manually or by unplugging the cable, the > problem doesn't appear to exist. Calling ifupdown may be inserted into > the suspend/resume scripts. I wonder why this isn't done by default. -- Vincent Lefèvre - Web:

Bug #302907 - maintainer doesn't reply

Bug #302907 in libstroke0-dev has been open and had a (working) patch for 6 years. The maintainer has never replied or done anything else concerning this bug. Could this bug be eventually fixed? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: .la file status and hint to clear the dependency_libs field

On 2011-05-27 00:17:45 +0200, Michael Biebl wrote: > Am 26.05.2011 23:26, schrieb Luk Claes: > > > There are some good reasons to keep some specific *.la files around, > > Just curious: what are these reasons / use case for keeping la files? They are at least read by libtool. For instance, when

Re: .la file status and hint to clear the dependency_libs field

On 2011-05-30 12:16:13 +0100, Simon McVittie wrote: > libtool .la files are useful if: > > * you're linking against a library installed in a directory that isn't > searched by the dynamic linker by default (e.g. installing a local > library in --prefix=$HOME, and a program that links that libr

Re: Multiarch in Debian unstable

Hi, On 2011-06-27 11:54:53 +0100, Steve Langasek wrote: > Work is ongoing to formulate a proper, distribution-neutral interface for > querying the correct multiarch path for a system. In the meantime, if you > are an upstream affected by this issue, or a maintainer of a package whose > upstream i

Re: Multiarch in Debian unstable

On 2011-06-27 15:42:47 +0100, Steve Langasek wrote: > On Mon, Jun 27, 2011 at 03:31:24PM +0200, Vincent Lefevre wrote: > > How libraries are searched is not clear, but depending on how this > > is done, there may be compatibility issues when the user installs > > software in h

Re: Multiarch in Debian unstable

On 2011-06-27 15:59:27 +0100, Simon McVittie wrote: > If by "fat binaries" you mean executables, No, I meant libraries (the term "fat binary" is used by the GMP library, but is here restricted to x86 subarchs). > If by "fat binaries" you mean shared libraries, they could either go in > /usr/lib,

Re: Multiarch in Debian unstable

On 2011-06-28 09:54:34 +0100, Steve Langasek wrote: > On Tue, Jun 28, 2011 at 02:05:05AM +0200, Vincent Lefevre wrote: > > > > http://gcc.gnu.org/ml/gcc-help/2010-11/msg00341.html > > > > This particular issue will not occur with multiarch, because > > >

Re: Multiarch in Debian unstable

On 2011-06-28 10:34:14 +0100, Steve Langasek wrote: > On Tue, Jun 28, 2011 at 07:40:03AM +0200, Hendrik Sattler wrote: > > Am Montag, 27. Juni 2011, 16:20:23 schrieb Steve Langasek: > > > So this: > > > > So it should be a matter of changing that to print this instead on > > > > Debian > > > > mul

Re: /usr/share/doc/ files and gzip/xz/no compression

On 2011-08-15 23:29:17 -0400, James Vega wrote: > You mean like lesspipe(1)? Seems like it might need to be updated to > handle *.xz, but other than that looks like it fits the bill. lesspipe(1) from the less package is a bit primitive. How about using Wolfgang Friebel's version, which already su

length of a package extended description

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 "Descript

Re: length of a package extended description

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 - Web:

Re: length of a package extended description

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 po

Re: length of a package extended description

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

Re: length of a package extended description

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 - Web:

Re: length of a package extended description

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' '

Re: length of a package extended description

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 line

Re: length of a package extended description

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: > > > >

Re: length of a package extended description

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

Re: length of a package extended description

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, AT&T ksh93, zsh (Debian sid). > I don’t see why it shouldn’t work on

Re: length of a package extended description

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, AT&T ksh93, zsh (Debian sid). >

Re: length of a package extended description

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

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

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-mai

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

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 basic

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

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

Re: linking perl statically against libperl

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

Re: linking perl statically against libperl

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. C

Re: Packages to install be default for Stretch

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 ava

emacsen-common (was: Packages to install be default for Stretch)

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

Re: Packages to install be default for Stretch

On 2015-05-06 11:21:13 +0200, Marco d'Itri wrote: > On May 05, Ansgar Burchardt 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 everywhere!

Re: Packages to install be default for Stretch

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

Re: Proposal: enable stateless persistant network interface names

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. :-( --

Re: Proposal: enable stateless persistant network interface names

On 2015-05-12 22:31:43 +0200, Marc Haber wrote: > On Tue, 12 May 2015 17:08:33 +0200, Vincent Lefevre > 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

Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

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 (dist-)up

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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: > >

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

On 2015-06-14 18:43:33 +0200, Marc Haber wrote: > On Sun, 14 Jun 2015 16:03:32 +0200, Vincent Lefevre > wrote: > >Normally, a well-designed dependency system should make sure that the > >user cannot install an incorrect combination of packages (avoiding > >segmentation fa

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

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

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

On 2015-06-15 18:56:47 +0200, Andreas Metzler wrote: > Vincent Lefevre 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 b

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

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 shou

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

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 t

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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. >

Re: Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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 Fi

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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 tole

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

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 s

Re: Debian with HiDPI / 4K displays

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

Re: Debian with HiDPI / 4K displays

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 fr

the status of gstreamer1.0-plugins-bad

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 l

Re: the status of gstreamer1.0-plugins-bad

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. -- Vin

Re: no{thing} build profiles

On 2018-10-24 10:33:30 +0100, Jonathan Dowland wrote: > That is sort-of what is happening for neomutt (20171215+dfsg.1-1) > at least, it reports > >sh: 1: gpg: not found > > There's room for improvement there. mutt (1.9.2-1) is worse > >Error: verification failed: Unsupported protocol >

Potentially insecure Perl scripts

Hi, I've just reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269 against gropdf (also reported upstream to bug-groff), about the use of the insecure null filehandle "<>" in Perl, which can lead to arbitrary command execution, e.g. when using wildcards. I've noticed that some ot

<    1   2   3   4   >