* Jonathan Nieder , 2012-11-21, 01:48:
This should be a standard interface via DEB_BUILD_OPTIONS, because
dh_builddeb / dpkg-deb is not the only way to build compliant binary
packages.
Policy §4.9 explains:
Both binary-* targets should depend on the build target, or on the
appropriate build-
Hi Dmitrijs,
Dmitrijs Ledkovs wrote:
> This should be a standard interface via DEB_BUILD_OPTIONS, because
> dh_builddeb / dpkg-deb is not the only way to build compliant binary
> packages.
Policy §4.9 explains:
Both binary-* targets should depend on the build target, or on the
appropriate b
On 20 November 2012 23:21, Guillem Jover wrote:
> On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote:
>> On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote:
>> Okay. I did some tests with various packages. From binary only to text
>> only.
>
> Thanks for the tests Bastian. It wou
On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote:
> On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote:
> Okay. I did some tests with various packages. From binary only to text
> only.
Thanks for the tests Bastian. It would still be nice to see a bigger
sample, if the tests on
On Tue, 2012-11-20 at 19:48:25 +, Thorsten Glaser wrote:
> Dmitrijs Ledkovs debian.org> writes:
> > Gzip is ok, but many packages these days use xz -9 --extreme deb
>
> xz is fine but -9 is abuse of the flexibility…
> maybe I should export XZ_DEFAULTS=--memlimit=150MiB
> in my build chroots…
Dmitrijs Ledkovs debian.org> writes:
> Gzip is ok, but many packages these days use xz -9 --extreme deb
xz is fine but -9 is abuse of the flexibility…
maybe I should export XZ_DEFAULTS=--memlimit=150MiB
in my build chroots… hmm… something to think about…
(for m68k, I might actually use less, set
On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote:
> There used to be a single global default level (9) for all compressors,
> which got changed in 2010 to be backend specific, but only xz and lzma
> were reduced to 6. I don't have any problem with changing gzip (to its
> upstream defau
Hi!
On Fri, 2012-11-09 at 10:16:21 +, Dmitrijs Ledkovs wrote:
> On 9 November 2012 09:37, Simon McVittie wrote:
> > (It's possible that "faster" presets don't actually give you more
> > performance if the time to write out the .deb is dominated by I/O,
> > though.)
>
> True about I/O. Does d
Hi!
On Fri, 2012-11-09 at 15:52:53 +0100, Bastian Blank wrote:
> On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote:
> > | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in
> > `test.gzip.deb'.
> > | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb
> > 62
On 9 November 2012 14:52, Bastian Blank wrote:
> On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote:
>> | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in
>> `test.gzip.deb'.
>> | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb
>> 62.96s user 1.78s syst
On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote:
> | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'.
> | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb 62.96s
> user 1.78s system 101% cpu 1:03.77 total
Some further tests show clearl
On Thu, Nov 08, 2012 at 04:33:42PM -0800, Russ Allbery wrote:
> Oh, okay. It would actually be much easier to standardize a way to switch
> to gzip compression than it would be to add a new concept of uncompressed
> packages.
The problem is: dpkg-deb with gzip is much slower than with bzip2 and x
On 9 November 2012 09:37, Simon McVittie wrote:
> On 08/11/12 19:31, Dmitrijs Ledkovs wrote:
>> I would like to have a nocompress Debian build option that will skip
>> any compression/optimisation at build time.
>
I am sorry if this was misleading. I am aware of the noopt option and
I am aware th
On 08/11/12 19:31, Dmitrijs Ledkovs wrote:
> I would like to have a nocompress Debian build option that will skip
> any compression/optimisation at build time.
That seems like mixing two orthogonal things: an uncompressed or
fastest-possible-compression .deb or source package, and speeding up
comp
On 9 November 2012 00:54, Adam Borowski wrote:
> On Thu, Nov 08, 2012 at 03:39:55PM -0800, Russ Allbery wrote:
>> Dmitrijs Ledkovs writes:
>>
>> > I would like to have a nocompress Debian build option that will skip any
>> > compression/optimisation at build time.
>>
>> > Specifically dpkg-buildd
On Thu, Nov 08, 2012 at 03:39:55PM -0800, Russ Allbery wrote:
> Dmitrijs Ledkovs writes:
>
> > I would like to have a nocompress Debian build option that will skip any
> > compression/optimisation at build time.
>
> > Specifically dpkg-builddeb and dpkg-source should use not use any
> > compress
On 9 November 2012 00:33, Russ Allbery wrote:
> Dmitrijs Ledkovs writes:
>
>> Gzip is ok, but many packages these days use xz -9 --extreme deb options
>> which is not fast at all on my pandaboard nor on my cloud instances with
>> capped CPU & memory. Using such compression is good for release de
Dmitrijs Ledkovs writes:
> Gzip is ok, but many packages these days use xz -9 --extreme deb options
> which is not fast at all on my pandaboard nor on my cloud instances with
> capped CPU & memory. Using such compression is good for release debs,
> but not in developer testing. It wastes develop
On 8 November 2012 23:39, Russ Allbery wrote:
> Dmitrijs Ledkovs writes:
>
>> I would like to have a nocompress Debian build option that will skip any
>> compression/optimisation at build time.
>
>> Specifically dpkg-builddeb and dpkg-source should use not use any
>> compression methods.
>
> Why
Dmitrijs Ledkovs writes:
> I would like to have a nocompress Debian build option that will skip any
> compression/optimisation at build time.
> Specifically dpkg-builddeb and dpkg-source should use not use any
> compression methods.
Why do you think this would be of any benefit? gzip compressi
I would like to have a nocompress Debian build option that will skip
any compression/optimisation at build time.
Specifically dpkg-builddeb and dpkg-source should use not use any
compression methods.
Similarly other tools can optionally listen on that variable e.g.
skipping pkgmangler and dh_scou
21 matches
Mail list logo
