Aron Xu writes:
> On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow wrote:
>> Aron Xu writes:
>>
>>> But what if I endianness does matters for those gettext .mo files?
>>> Installing them as libfoo-translations-be and libfoo-translations-le
>>> will need some change in gettext support of thos
On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow wrote:
> Aron Xu writes:
>
>> But what if I endianness does matters for those gettext .mo files?
>> Installing them as libfoo-translations-be and libfoo-translations-le
>> will need some change in gettext support of those
>> applications/librari
On 30/04/12 15:21, Goswin von Brederlow wrote:
> With libfoo being in /usr/lib// any endian dependent data
> should be in /usr/lib/// or /usr/lib/ tuple>// (sorry, did we pick one of them as standard yet?),
> which is usualy a configure option.
I think you mean /usr/lib// for the second option?
I
Aron Xu writes:
> But what if I endianness does matters for those gettext .mo files?
> Installing them as libfoo-translations-be and libfoo-translations-le
> will need some change in gettext support of those
> applications/libraries, that is finding mo files in alternative paths,
> and choosing t
On Fri, Apr 27, 2012 at 16:46, Goswin von Brederlow wrote:
> Aron Xu writes:
>
>> On Thu, Apr 26, 2012 at 23:21, Osamu Aoki wrote:
>>> Hi,
>>>
>>> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
> If a packa
Aron Xu writes:
> On Thu, Apr 26, 2012 at 23:21, Osamu Aoki wrote:
>> Hi,
>>
>> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
>>> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>>>
>>> > If a package is marked as "Multi-Arch: same", files with the same
>>> > name hav
On Fri, Apr 27, 2012 at 00:30:01 +0900, Osamu Aoki wrote:
> Hi,
>
> Just removing Multi-Arch causes this lintian warning ...
>
> W: ibus source: dependency-is-not-multi-archified libibus-1.0-dev
> depends on gir1.2-ibus-1.0 (multi-arch: no)
> N:
> N:The package is Multi-Arch "same", but it
On Fri, Apr 27, 2012 at 00:21:20 +0900, Osamu Aoki wrote:
> I also see for libopencc1 (not mine but I am watching it...)
>
> [libopencc1 0.3.0-2]
> usr/share/locale/zh_CN/LC_MESSAGES/opencc.mo
> 2c2024df5378074f4727948eb7133516 mips s390 sparc s390x powerpc
> 6a7df4d7f1f5383bd7461de8a0bb4957
On Thu, Apr 26, 2012 at 23:21, Osamu Aoki wrote:
> Hi,
>
> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
>> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>>
>> > If a package is marked as "Multi-Arch: same", files with the same
>> > name have to be (byte-to-byte) iden
Hi,
Just removing Multi-Arch causes this lintian warning ...
W: ibus source: dependency-is-not-multi-archified libibus-1.0-dev
depends on gir1.2-ibus-1.0 (multi-arch: no)
N:
N:The package is Multi-Arch "same", but it depends on a package that
is
N:neither Multi-Arch "same" nor "foreign"
Hi,
On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>
> > If a package is marked as "Multi-Arch: same", files with the same
> > name have to be (byte-to-byte) identical across all architectures.
> > Unfortunately, not all
On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
> If a package is marked as "Multi-Arch: same", files with the same
> name have to be (byte-to-byte) identical across all architectures.
> Unfortunately, not all packages obey this requirement. I set up a
> page to track violators:
>
> htt
* Jakub Wilk , 2011-11-17, 20:03:
The most common reasons for cross-architecture differences appear to be
(in random order):
[...]
- Using gzip without the -n option.
This is now detected by lintian >= 2.5.4.
[...]
- Including /usr/lib/debug/usr/bin/* stuff in -dbg package.
debhelper >= 8
On Sat, Nov 19, 2011 at 10:55:53AM +, Neil Williams wrote:
> As long as the behaviour is always *consistent* across native builds and
> cross-builds, I would be happy with having all .mo files with the same
> endianness. By preference, little endian.
I agree; little-endian is both the most com
On Sun, 2011-11-20 at 12:30 -0600, Peter Samuelson wrote:
> [Goswin von Brederlow]
> > Ugly, but if it works ... You only have those 2 choices for Multi-Arch:
> > same: Split the package or make the files equal.
>
> Well, the third choice is to assume nobody _really_ cares about
> multiarch for JN
Am Sonntag, 20. November 2011, 19:30:45 schrieb Peter Samuelson:
> [Goswin von Brederlow]
>
> > Ugly, but if it works ... You only have those 2 choices for Multi-Arch:
> > same: Split the package or make the files equal.
>
> Well, the third choice is to assume nobody _really_ cares about
> multia
On Sun, Nov 20, 2011 at 12:30:45PM -0600, Peter Samuelson wrote:
> [Goswin von Brederlow]
> > Ugly, but if it works ... You only have those 2 choices for Multi-Arch:
> > same: Split the package or make the files equal.
> Well, the third choice is to assume nobody _really_ cares about
> multiarch f
* Peter Samuelson , 2011-11-20, 02:34:
(cd TMP; find | sort | xargs zip -9 ../TMP.zip {} +)
FYI, zip has -@ option, that makes it read filenames from standard
input. This should be more robust that using xargs.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.
Op Sun, 20 Nov 2011 12:30:45 -0600
schreef Peter Samuelson :
> I tried repacking, but can't get zip to produce consistent output,
> even on a single platform. Looks like there's one byte per stored
> directory, and two bytes per stored file, that change on each 'zip'
> invocation. I'm testing wi
[Goswin von Brederlow]
> Ugly, but if it works ... You only have those 2 choices for Multi-Arch:
> same: Split the package or make the files equal.
Well, the third choice is to assume nobody _really_ cares about
multiarch for JNI libraries, and just drop the Multi-Arch: header.
> Since you are b
Peter Samuelson writes:
> [Jakub Wilk]
>> If a package is marked as "Multi-Arch: same", files with the same
>> name have to be (byte-to-byte) identical across all architectures.
>> Unfortunately, not all packages obey this requirement.
>
> [libsvn-java 1.6.17dfsg-2+b1]
> usr/share/java/sv
On Sb, 19 nov 11, 10:32:53, John D. Hendrickson and Sara Darnell wrote:
>
> can't i delete .mo locally if i'm bitwise desperate for disk space?
$ apt-cache show localepurge
Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo
[Jakub Wilk]
> If a package is marked as "Multi-Arch: same", files with the same
> name have to be (byte-to-byte) identical across all architectures.
> Unfortunately, not all packages obey this requirement.
[libsvn-java 1.6.17dfsg-2+b1]
usr/share/java/svn-javahl.jar
This file is in a pac
From: john hendrickson
Josselin your response is obstructive rather than productive.
If you have a vested interest in obstructed Debian you must make that known in
the outset, capice?
Josselin Mouette wrote:
Or in legacy; I've read about wishes of their own patent problems,
capice? But ads
Or in legacy; I've read about wishes of their own patent problems,
capice? But ads a login can get out and having to be opensuse deeply
compatible yet high unix efficient, Switching to all the road? Grub and
having to maintain and inodes would be my slice single project need
change if MIS USED by
not that i'm multi-lingual (i use google to translate!)
don't we get all .mo avail. in packages already? (i hope)
# locate "*.mo" | wc
13341 13341 648305
... and if build/tar admins say "choose another method" why not try asking them
what?
can't i delete .mo locally if i'm bitwise despe
hi. i'm not an "admin" but. are you sure compression routines guarantee the same compression for
the same file? and when given differing directory names?
I have a hard time wrapping my head around your statement: gzip is "erroneous".
Have fun, John Hendrickson
look at my quick test ...
#
Hi,
Le jeudi 17 novembre 2011 à 20:03 +0100, Jakub Wilk a écrit :
> http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
> http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist
>
> (If there is no MD5 sum information next to a file name, it means that
> the sum for each architec
On Fri, 18 Nov 2011 23:39:20 -0600
Peter Samuelson wrote:
>
> [Jakub Wilk]
> > The most common reasons for cross-architecture differences appear to
> > be (in random order):
>
> > - Compiling GNU message catalogs with gettext, which uses native
> > endianness (see bug #468209).
(Hmm, I did get
[Jakub Wilk]
> The most common reasons for cross-architecture differences appear to
> be (in random order):
> - Compiling GNU message catalogs with gettext, which uses native
> endianness (see bug #468209).
Having read that bug log, it's not clear to me whether there's a
consensus about what to
If a package is marked as "Multi-Arch: same", files with the same name
have to be (byte-to-byte) identical across all architectures.
Unfortunately, not all packages obey this requirement. I set up a page
to track violators:
http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
http://pe
31 matches
Mail list logo
