Russ Allbery r...@debian.org writes:
Goswin von Brederlow goswin-...@web.de writes:
Changing the name in the package would break tools that rely on the name
(like packages.debian.org extracting the Changelog). Also ugly.
We control the tools; we can change the tools. Multiarch is a big
On Sun, Feb 12, 2012 at 08:00, Carsten Hey cars...@debian.org wrote:
* Aron Xu [2012-02-09 01:22 +0800]:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. ...
Steve Langasek writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
And what about adding 700 packages vs. adding no packages at all, in the
case of systems which aren't going to have multiarch enabled?
One thing that seems to have been overlooked in this discussion
I wrote:
Or to put it another way: if currently
libfoo1 (1.1) contains and needs /usr/share/libfoo1/foo-data-1.1
libfoo1 (1.2) contains and needs /usr/share/libfoo2/foo-data-1.2
then splitting the foo-data out into
libfoo1-data (1.1) -depends- libfoo1 (1.1)
libfoo1-data (1.2)
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I wrote:
Or to put it another way: if currently
libfoo1 (1.1) contains and needs /usr/share/libfoo1/foo-data-1.1
libfoo1 (1.2) contains and needs /usr/share/libfoo2/foo-data-1.2
then splitting the foo-data out into
libfoo1-data (1.1)
Steve Langasek vor...@debian.org writes:
On Thu, Feb 09, 2012 at 01:40:41PM +0100, Goswin von Brederlow wrote:
Steve Langasek vor...@debian.org writes:
- For many of these files, it would be actively harmful to use
architecture-qualified filenames. Manpages included in -dev packages
Cyril Brulebois dixit:
For those not subscribed to that bug, how to reproduce[1] and possible
fix[2] are available now. There might be other places where buffers are
reused, I only spent a few minutes on this during my lunch break.
Your lunch breaks are amazing. Doesn’t this look like “uses
* Aron Xu [2012-02-09 01:22 +0800]:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. ...
Debian Policy, begin of section 5.6.8:
| Depending on context and the
Steve Langasek vor...@debian.org writes:
On Thu, Feb 09, 2012 at 10:29:53PM +0100, Guillem Jover wrote:
But the more interesting slowdown is that the amount of packages is general
slows down apt operations in a rate that is around O(dependencies^2) (pure
guess,
perhaps someone has
On Fri, Feb 10, 2012 at 12:47:20PM +0100, Goswin von Brederlow wrote:
That's based on a sample of 1200 packages currently tagged Multi-Arch:
same in the Ubuntu precise archive. If we have all packages in sections
libs and libdevel converted for multiarch (which I suppose we eventually
* Guillem Jover guil...@debian.org, 2012-02-09, 03:45:
But anyway, I believe that in the long run we should simply deprecate
compressing stuff in /usr/share/doc/.
So the main reason people are arguing for shared files boils down to
used size, either in installed files, or Packages files, etc,
Bastian Blank writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
On Thu, Feb 09, 2012 at 11:45:52AM -0400, Joey Hess wrote:
And then if I have a multiarch system, and want to locally download the
source of some library, build it and install it, dpkg will complain if I
Steve Langasek vor...@debian.org writes:
And what about adding 700 packages vs. adding no packages at all, in the
case of systems which aren't going to have multiarch enabled?
This would impact systems of all archs, not just those for which multiarch
is a significant use case.
I'm having a
On Thu, Feb 09, 2012 at 01:40:41PM +0100, Goswin von Brederlow wrote:
Steve Langasek vor...@debian.org writes:
- For many of these files, it would be actively harmful to use
architecture-qualified filenames. Manpages included in -dev packages
should not change names based on the
On Thu, Feb 09, 2012 at 01:58:28AM +0800, Aron Xu wrote:
On Thu, Feb 9, 2012 at 01:35, Simon McVittie s...@debian.org wrote:
On 08/02/12 17:22, Aron Xu wrote:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all
On Thu, Feb 09, 2012 at 03:45:50AM +0100, Guillem Jover wrote:
While this could benefit the multiarch installations (for which they
can easily use --path-exclude), it would use lots more space on single
arch installations.
Does it really?
A quick test tells me that uncompressing every file
Josh Triplett j...@joshtriplett.org writes:
The only downside that I can see: packages couldn't refer to a
particular file under /usr/share/doc/$package/ by path, because those
packages wouldn't know how the administrator might choose to compress
their files. Given the policy of not
Adam Borowski kilob...@angband.pl writes:
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
For those not subscribed to that bug, how to reproduce[1] and possible
fix[2] are available now. There might be other places where buffers are
reused, I only spent a few minutes on this
On Thu, Feb 09, 2012 at 01:33:58AM +, Wookey wrote:
Some of the issues are already clear I think (moving arch-dependent
headers into arch-qualified dirs, but leaving the others where they
are)
And what is considered the best way to share the architecture–independent
headers between M-A:
Guillem Jover guil...@debian.org writes:
On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote:
In practice, the only compressor we need to care is gzip, which is
not actively maintained upstream[0]. Chances that a new version of
it will break large number of packages are minute.
That
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
Another possible solution is to just give any package an implicit Replaces
(possibly constrained to /usr/share/doc) on any other package with the
same
Steve Langasek vor...@debian.org writes:
- For many of these files, it would be actively harmful to use
architecture-qualified filenames. Manpages included in -dev packages
should not change names based on the architecture; having
/usr/share/pam-config contain multiple files for
Goswin von Brederlow writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
One thing which no-one yet seems to have suggested is to have
multiarch:same packages put the changelog in a filename which is
distinct
Wouter Verhelst wou...@debian.org writes:
On Thu, Feb 09, 2012 at 03:45:50AM +0100, Guillem Jover wrote:
While this could benefit the multiarch installations (for which they
can easily use --path-exclude), it would use lots more space on single
arch installations.
Does it really?
A quick
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Goswin von Brederlow writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
One thing which no-one yet seems to have suggested is to have
multiarch:same packages
Goswin von Brederlow wrote:
* after a bugfix (including security ones)
Yes, but not a problem (other than a small race condition) since all
buildds should have the same version.
And then if I have a multiarch system, and want to locally download the
source of some library, build it and
On Wed, Feb 08, 2012 at 03:06:46PM +0100, Adam Borowski wrote:
gzip's output is likely to change:
* on a different architecture
* with different optimizations
If either of these are the case (assuming a valid, deterministic,
non-arch-specific implementation) then this violates C's as-if rule.
On Thu, Feb 09, 2012 at 11:45:52AM -0400, Joey Hess wrote:
And then if I have a multiarch system, and want to locally download the
source of some library, build it and install it, dpkg will complain if I
didn't use the same gzip that was used to build other arch versions I
have installed.
On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote:
Riku mentioned as an argument that this increases the data to download
due to slightly bigger Packages files, but pdiffs were introduced
exactly to fix that problem. And, as long as the packages do not get
updated one should not
Goswin von Brederlow goswin-...@web.de writes:
Changing the name in the package would break tools that rely on the name
(like packages.debian.org extracting the Changelog). Also ugly.
We control the tools; we can change the tools. Multiarch is a big deal.
We weren't going to get through this
On Thu, 2012-02-09 at 21:50:17 +0200, Riku Voipio wrote:
On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote:
Riku mentioned as an argument that this increases the data to download
due to slightly bigger Packages files, but pdiffs were introduced
exactly to fix that problem. And,
On Thu, Feb 09, 2012 at 10:29:53PM +0100, Guillem Jover wrote:
But the more interesting slowdown is that the amount of packages is general
slows down apt operations in a rate that is around O(dependencies^2) (pure
guess,
perhaps someone has better knowledge?). We do remember apt-get
On Thu, Feb 9, 2012 at 22:29, Guillem Jover guil...@debian.org wrote:
On Thu, 2012-02-09 at 21:50:17 +0200, Riku Voipio wrote:
On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote:
Riku mentioned as an argument that this increases the data to download
due to slightly bigger Packages
On Wed, Feb 08, 2012 at 03:06:46PM +0100, Adam Borowski wrote:
gzip's output is likely to change:
* on a new version
* after a bugfix (including security ones)
* on a different architecture
* with different optimizations
* with a different implementation (like those parallel ones)
*
Sorry, the thread was broken and I saw your reply just now.
On Thu, Feb 9, 2012 at 16:23, Jan Hauke Rahm j...@debian.org wrote:
On Thu, Feb 09, 2012 at 01:58:28AM +0800, Aron Xu wrote:
This is valid for most-used applications/formats like gettext, images
that are designed to behave in this
On Thu, Feb 09, 2012 at 02:54:43PM +0100, Goswin von Brederlow wrote:
Wouter Verhelst wou...@debian.org writes:
On Thu, Feb 09, 2012 at 03:45:50AM +0100, Guillem Jover wrote:
While this could benefit the multiarch installations (for which they
can easily use --path-exclude), it would use
On Wed, 8 Feb 2012 12:05:44 +1100
Russell Coker russ...@coker.com.au wrote:
On Wed, 8 Feb 2012, Riku Voipio riku.voi...@iki.fi wrote:
If it turns out not reasonable to expect the compression results to be
identical
It was reported that sometimes the size differs. Surely if nothing else
On Wed, 8 Feb 2012 02:52:52 +0200
Riku Voipio riku.voi...@iki.fi wrote:
If it turns out not reasonable to expect the compression results to be
identical, we should probably look into using dpkg --path-exclude= with
/usr/share/{doc,man,info}/* when installing foreign-architecture packages.
* Lars Wirzenius l...@liw.fi [120208 08:58]:
On Tue, Feb 07, 2012 at 10:49:23PM +, 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's
potentially necessary to fix up the md5sums
On Wed, 8 Feb 2012, Neil Williams codeh...@debian.org wrote:
Expecting that the compression gives the smallest file every time is
reasonable.
By a single byte - I've not seen file size changes beyond that range.
It's a matter of principle. A compression program is supposed to reliably
On Wed, 8 Feb 2012 21:54:30 +1100
Russell Coker russ...@coker.com.au wrote:
On Wed, 8 Feb 2012, Neil Williams codeh...@debian.org wrote:
Expecting that the compression gives the smallest file every time is
reasonable.
By a single byte - I've not seen file size changes beyond that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/2012 11:04 PM, Neil Williams wrote:
I'm not convinced that this is fixable at the gzip level, nor is it
likely to be fixable by the trauma of changing from gzip to
something else.
while the original point of not considering compressors
On 08/02/12 10:22, Neil Williams wrote:
Nothing in /usr/share/ matters for a cross package created by
dpkg-cross (with the possible exception of /usr/share/pkg-config
which was always anachronistic).
I'd understood that /usr/share/pkgconfig should be used for the
sort of packages that would
On Wed, 2012-02-08 at 07:57 +, Lars Wirzenius wrote:
On Tue, Feb 07, 2012 at 10:49:23PM +, 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's
potentially necessary to fix up the
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
Maybe the way to solve this properly is to remove compression from the
uniqueness check - compare the contents of the file in memory after
decompression. Yes, it will take longer but it is only needed when the
md5sum (which already
Neil Williams codeh...@debian.org (07/02/2012):
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic behaviour of gzip -9n.
For those not subscribed to that bug, how to reproduce[1] and possible
(Dropping everyone but dd@.)
Wouter Verhelst wou...@debian.org (08/02/2012):
As an additional benefit, this will also allow those among us (like me)
who hate having to use 'gunzip -c /usr/share/doc/foo/bar.pdf.gz
/tmp/bar.pdf; xpdf /tmp/bar.pdf' in order to be able to read some
Russ Allbery writes (Re: Please test gzip -9n - related to dpkg with multiarch
support):
Another possible solution is to just give any package an implicit Replaces
(possibly constrained to /usr/share/doc) on any other package with the
same name and version and a different architecture
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
For those not subscribed to that bug, how to reproduce[1] and possible
fix[2] are available now. There might be other places where buffers are
reused, I only spent a few minutes on this during my lunch break.
2.
Wouter Verhelst wrote:
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
Maybe the way to solve this properly is to remove compression from the
uniqueness check - compare the contents of the file in memory after
decompression. Yes, it will take longer but it is only needed when
On Wed, 8 Feb 2012 14:14:22 +0100
Cyril Brulebois k...@debian.org wrote:
Neil Williams codeh...@debian.org (07/02/2012):
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic behaviour of gzip
On Wed, Feb 08, 2012 at 11:33:37AM +0100, Bernhard R. Link wrote:
On the other hand most uncompressors silently ignore unexpected
data after end of file markers. So the compressed file is even more
easily tempered with (especially as debsums only stores md5 without
size and md5 does not
On Wed, 8 Feb 2012 15:06:46 +0100
Adam Borowski kilob...@angband.pl wrote:
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
For those not subscribed to that bug, how to reproduce[1] and possible
fix[2] are available now. There might be other places where buffers are
reused,
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just seems even
more fragile than the shared files
On Wed, Feb 08, 2012 at 05:13:20PM +0100, Guillem Jover wrote:
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
If you remove the shared files approach, how do you handle files like
lintian overrides, reportbug presubj and scripts, etc. ?
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's
Guillem Jover writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
One thing which no-one yet seems to have suggested is to have
multiarch:same packages put the changelog in a filename which is
distinct
I want to speak up about endianness of data files, this is a
suggestion but not a flaw which I just want to discover the
possibility of improvement to current status by the chance of
implementing Multi-Arch in Debian.
Some packages come with data files that endianness matters, and many
of them
Ian Jackson wrote:
Another relevant question is whether there are other files that are
shared, and which don't want to move, besides ones in /usr/share/doc.
One example is header files in /usr/include, from -dev packages. In
the simple examples I've seen, putting them in /usr/include/triplet,
On 08/02/12 17:22, Aron Xu wrote:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. AFAIK some maintainers
are not aware of endianness issues in their packages
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
If you remove the shared files approach, how do you handle files like
lintian overrides, reportbug presubj and scripts, etc. ?
The same principle that applies to all dpkg
On Thu, Feb 9, 2012 at 01:35, Simon McVittie s...@debian.org wrote:
On 08/02/12 17:22, Aron Xu wrote:
Some packages come with data files that endianness matters, and many
of them are large enough to split into a separate arch:all package if
endianness were not something to care about. AFAIK
On Wed, 8 Feb 2012 17:13:20 +0100
Guillem Jover guil...@debian.org wrote:
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.
Instead of this, I'd rather
On Wed, 08 Feb 2012, Neil Williams wrote:
I don't get it. That would only affect packages which were built
during the time that a new upload of gzip is made and all the
buildd's making that new version available. Now, if there is a
binNMU after a new version of gzip is uploaded, yes it is
Guillem Jover guil...@debian.org writes:
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just
On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
Guillem Jover guil...@debian.org writes:
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
And while the binNMU changelog issues might seem like a corner case,
it's just a symptom of something that's not quite right.
Riku Voipio riku.voi...@iki.fi writes:
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's a “Multi-Arch: same” package
name that needs to be unambiguous, it just always
On Wed, 2012-02-08 at 11:25:28 -0800, Don Armstrong wrote:
On Wed, 08 Feb 2012, Neil Williams wrote:
I don't get it. That would only affect packages which were built
during the time that a new upload of gzip is made and all the
buildd's making that new version available. Now, if there is a
Guillem Jover guil...@debian.org writes:
Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
sid generating a reproducible output across all current architectures.
Time passes, compressor version N (and even O and P and Q etc) gets
uploaded, which starts producing new ouput
Roger Leigh rle...@codelibre.net writes:
On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
Also true. In fact, it's something that's been bothering me for a long
time with linked doc directories. I'd like to prohibit them in more
cases so that we get the binNMU changelogs on
On Wed, 08 Feb 2012 11:56:06 -0800
Russ Allbery r...@debian.org wrote:
There are two main cases for libfoo-dev that I think cover most such
packages:
1. The header files are architecture-dependent (definitions of data member
sizes, for example), in which case they need to be
Joey Hess jo...@debian.org writes:
pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required
to always produce the same compressed file for a given input file, and I
can tell you from experience that there is a wide amount of
variation. If multiarch requires this, then its design
On Wed, Feb 08, 2012 at 07:54:47PM +, Roger Leigh wrote:
On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
Guillem Jover guil...@debian.org writes:
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
And while the binNMU changelog issues might seem like a corner case,
On Wed, 2012-02-08 at 11:56:06 -0800, Russ Allbery wrote:
Riku Voipio riku.voi...@iki.fi writes:
That is a major waste of space of having multiple copies of identical
files with different arch-qualified names. Is that really better
architecture to have multiple copies of identical files on
* Ben Hutchings b...@decadent.org.uk, 2012-02-08, 20:23:
Relating to binNMU changelogs: do they really serve any purpose?
There are no source changes, so is there any real need for a changelog
change at all? AFAICT the only reason we do for historical reasons,
it being the only way previously
On Wed, Feb 08, 2012 at 09:02:43PM +0100, Guillem Jover wrote:
Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
sid generating a reproducible output across all current architectures.
Time passes, compressor version N (and even O and P and Q etc) gets
uploaded, which
* Guillem Jover guil...@debian.org, 2012-02-08, 21:02:
Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
sid generating a reproducible output across all current architectures.
Time passes, compressor version N (and even O and P and Q etc) gets
uploaded, which starts
On 2012-02-08, Russ Allbery r...@debian.org wrote:
There are two main cases for libfoo-dev that I think cover most such
packages:
3) to ensure that things can keep working on slow archs while they build
a new edition of src:foo
/Sune
--
To UNSUBSCRIBE, email to
Neil Williams codeh...@debian.org writes:
Russ Allbery r...@debian.org wrote:
There are two main cases for libfoo-dev that I think cover most such
packages:
1. The header files are architecture-dependent (definitions of data member
sizes, for example), in which case they need to be
On Wed, Feb 08, 2012 at 11:56:06AM -0800, Russ Allbery wrote:
Riku Voipio riku.voi...@iki.fi writes:
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's a “Multi-Arch:
On Wed, Feb 08, 2012 at 10:22:17AM +, Neil Williams wrote:
After all, this is how cross/foreign architecture packages have
*always* been handled in Debian via dpkg-cross. Nothing in /usr/share/
matters for a cross package created by dpkg-cross (with the possible
exception of
Le Wed, Feb 08, 2012 at 07:54:47PM +, Roger Leigh a écrit :
Relating to binNMU changelogs: do they really serve any purpose? There
are no source changes, so is there any real need for a changelog change
at all? AFAICT the only reason we do for historical reasons, it being
the only way
Steve Langasek vor...@debian.org writes:
The unfounded assumption here is that you will always install a
foreign-arch M-A: same package together with the native-arch version.
If I install libaudio2:i386 because I want to play a game that's only
available as a 32-bit binary and has this lib as
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
The unfounded assumption here is that you will always install a
foreign-arch M-A: same package together with the native-arch version.
If I install libaudio2:i386 because I want to play a
Steve Langasek vor...@debian.org writes:
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
The unfounded assumption here is that you will always install a
foreign-arch M-A: same package together with the native-arch version.
If I install
+++ Russ Allbery [2012-02-08 13:47 -0800]:
Neil Williams codeh...@debian.org writes:
Russ Allbery r...@debian.org wrote:
Oh, good point, I'd forgotten that for multiarch the symlink is
architecture-dependent. So yes, the -dev package is inherently
architecture-dependent.
I would drop
On Wed, 2012-02-08 at 15:14:35 -0800, Steve Langasek wrote:
So I had a look at the Ubuntu archive, which already has a large collection
of packages converted to Multi-Arch: same, to provide some hard facts for
this discussion.
- 2197 files are shipped in /usr/share by these packages,
On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote:
In practice, the only compressor we need to care is gzip, which is
not actively maintained upstream[0]. Chances that a new version of
it will break large number of packages are minute.
That assumes that we will never want to switch to a
On Feb 09, Steve Langasek vor...@debian.org wrote:
I think there are pretty solid benefits to proceeding with a dpkg that
allows sharing files across M-A: same packages.
Agreed. Fix the tools instead of breaking the standard to adapt to
broken tools.
Myself, I like the idea of the implicit
On Mon, 6 Feb 2012 08:31:15 +0100
Raphael Hertzog hert...@debian.org wrote:
If you discover any bug in dpkg's multiarch implementation, please
report it to the BTS (against the version 1.16.2~wipmultiarch).
I'd like to ask for some help with a bug which is tripping up my tests
with the
On 07.02.2012 10:59, Neil Williams wrote:
It would be a very laborious task to check the md5sums of every .gz file
in /usr/share/doc in every MultiArch: same package across all
architectures and the Contents-* files on the mirrors don't contain the
filesize of the listed files. Does anyone
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic behaviour of gzip -9n.
pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required
to always produce the same
On 07.02.2012 18:07, Joey Hess wrote:
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic behaviour of gzip -9n.
pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz
Hi Joey,
On Tue, Feb 07, 2012 at 01:07:11PM -0400, Joey Hess wrote:
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic behaviour of gzip -9n.
pristine-tar hat tricks[1]
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl bi...@debian.org wrote:
On 07.02.2012 18:07, Joey Hess wrote:
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic
On Tue, 7 Feb 2012 14:01:57 -0800
Steve Langasek vor...@debian.org wrote:
There are various ways to meet both the multiarch constraints and the policy
requirements, including shipping an arch:all common package that will
contain the changelog for each multiarch library, which then ships just a
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl bi...@debian.org wrote:
On 07.02.2012 18:07, Joey Hess wrote:
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the
Neil Williams codeh...@debian.org writes:
Maybe the way to solve this properly is to remove compression from the
uniqueness check - compare the contents of the file in memory after
decompression. Yes, it will take longer but it is only needed when the
md5sum (which already exists) doesn't
On Tue, 07 Feb 2012, 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's
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256
Henrique de Moraes Holschuh wrote:
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256 uncompress) by the size of
the hash. Old debsums won't work with the new files, but is that really
a problem? That's what stable updates and
1 - 100 of 105 matches
Mail list logo
