pendency here.
Instead of adding another Multi-Arch value, how about adding
'Recommends: Y:every' to Y? (This also moves the problem up from dpkg
to APT.)
Ben.
> Any ideas on how to solve this problem?
--
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.
signature.asc
Description: This is a digitally signed message part
On Sun, 2015-05-03 at 16:52 +0200, Guillem Jover wrote:
> On Fri, 2015-05-01 at 13:24:56 +0100, Ben Hutchings wrote:
> > On Fri, 2015-05-01 at 05:51 +0200, Guillem Jover wrote:
> > > Although I cannot fetch from the repo:
> > >
> > > ,---
> > > $ git
On Fri, 2015-05-01 at 05:51 +0200, Guillem Jover wrote:
> On Mon, 2015-04-27 at 01:11:33 +0100, Ben Hutchings wrote:
> > On Thu, 2015-04-23 at 07:10 +0200, Guillem Jover wrote:
> >
> > I'd prefer if you merged and released the tarball, then I can do the
> > r
On Thu, 2015-04-23 at 07:10 +0200, Guillem Jover wrote:
> Hi!
>
> On Wed, 2015-04-22 at 01:53:16 +0100, Ben Hutchings wrote:
> > I've prepared an update to dpkg in squeeze-lts to fix CVE-2015-0840. As
> > it's a native package, I'd like to check some points w
happy to pull from my git branch, or should I send one or
multiple patches?
git repository:
http://git.decadent.org.uk/gitweb?p=dpkg.git;a=summary
http://git.decadent.org.uk/git/dpkg.git
packages:
https://people.debian.org/~benh/packages/squeeze-lts/
Ben.
--
Ben Hutchings
Humans are not
-c1 data.tar > /tmp/data.tar.gz
real0m2.557s
user0m2.528s
sys 0m0.028s
$ ls -l data.tar /tmp/data.tar.gz
-rw-r--r-- 1 ben ben 77352960 Dec 18 04:10 data.tar
-rw-rw 1 ben ben 77310312 Dec 18 04:11 /tmp/data.tar.gz
It seems there's enough zero-padding in the tar headers that g
On Sat, 2012-07-14 at 07:51 +0300, Martin-Éric Racine wrote:
> 2012/7/13 Ben Hutchings :
[...]
> If I disable CONFIG_DEBUG_INFO again just before building, the kernel
> indeed is MUCH smaller (I had probably forgotten to disable it before
> attempting a new build; sorry for the confu
; Or do you mean that the size of the kernel -dbg packages is
> > ridiculous?
>
> I mean that the size of the kernel package produced by 'make deb-pkg'
> from the 3.2 vanilla tree, even after disabling debug symbols, is
> highly suspicious,
On Wed, 2012-02-08 at 07:57 +, Lars Wirzenius wrote:
> On Tue, Feb 07, 2012 at 10:49:23PM +0000, Ben Hutchings wrote:
> > But it's worse than this: even if dpkg decompresses before comparing,
> > debsums won't (and mustn't, for backward compatibility). So it'
ns aside), where it does not
> match then dpkg cannot deem that the files conflict without creating a
> checksum based on the decompressed content of the two files.
[...]
But it's worse than this: even if dpkg decompresses before comparing,
debsums won't (and mustn't, f
On Sat, 2010-11-27 at 07:59 +0100, Guillem Jover wrote:
> Hi Ben!
>
> On Fri, 2010-11-26 at 13:31:20 +0000, Ben Hutchings wrote:
> > Just got this from Christoph Helwig:
> >
> > 13:23 < hch> bwh: if you guys are interested in helping dpkg review and ack
>
I know ext4
fsync isn't stellar, but the numbers sounds so bad that there must
be a bug somewhere
The patch referred to is in
<http://thread.gmane.org/gmane.linux.file-systems/44628>.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to im
uld make that the default? Is there anything
> else the dpkg developers can try to be portable and still not be
> sacrificing performance?
I'm coming to this late. It sounds like dpkg has changed its behaviour
several times recently. Please can you summarise dpkg's current and
pr
# Automatically generated email from bts, devscripts version 2.10.29~bpo40+1
reassign 497304 dpkg
forcemerge 68788 497304
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
14 matches
Mail list logo
