Re: List of packages which should probably be Architecture: all
Ok, I'm sorry for the long delay since the last reply, I've been very busy with real life. Cyril Brulebois wrote: I guess your scripts are somehow assuming that if one has an empty Depends line, the other has an empty line as well, or something similar. It only checks on one Packages, not both. I'm not blaming because of false positives. I'd expect more common sense. Either grub is architecture-dependent, being a low-level stuff, probably written in C (I know, that might sound like a cliché, but…), or it is just made out of supercowpowered architecture-independent shell scripts, but then one might wonder a bit. Seen where it belongs in a boot sequence? Reviewing such a short list takes some minutes (to compare with the time you spent on setting up these scripts), using the main measure when it comes to being “Architecture: all” or “Architecture: any”: its *content* (but you know that, I've been repeating this from the very beginning). I did expect that comparing the md5sums would easily show what packages are really arch all and which aren't. I'm now posting a list generated by the script but now also comparing with the .deb form powerpc. This is nothing but the raw list and should not be considered as a definitive rule (although it would be really odd to find a false positive in this list). I haven't reviewed the full list but at least I noticed that hol88-library appeared once again so I decided to quickly review the source package (the package is either cross compiling, or just installing pre-built binaries, or doing something similar). Using find shows some .o files under contrib/ but they don't seem to be the ones in hol88-library. Right now I don't have very much time to investigate a little further but all I can say is that its debian/rules isn't properly written because executing % debian/rules debian/hol88-library.install creates an empty file; it is generated by using find but I guess it requires the package to be built (hence the isn't properly written) something I didn't do before running that command. An other note: this time I've used --ignore-matching-lines=usr/share/doc/ --ignore-matching-lines=usr/share/man/ so it should give some *better* results. 2vcard *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums avahi-dbg: Files amd64/md5sums and i386/md5sums differ biosquid-dev: Files amd64/md5sums and i386/md5sums differ bld-tools *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums busybox-static: Files amd64/md5sums and i386/md5sums differ centerim-common: Files amd64/md5sums and i386/md5sums differ Processing cgilib...diff: amd64/md5sums: No such file or directory diff: i386/md5sums: No such file or directory cgilib: chasen-cannadic: Files amd64/md5sums and i386/md5sums differ Processing check... Processing cvm-dev... dar-static: Files amd64/md5sums and i386/md5sums differ dballe-common *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums dietlibc-dev: Files amd64/md5sums and i386/md5sums differ drac-dev: Files amd64/md5sums and i386/md5sums differ dvdbackup-dbg: Files amd64/md5sums and i386/md5sums differ Processing e2fsck-static... espeak-data *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums etl-dev: Files amd64/md5sums and i386/md5sums differ exim4-dev: Files amd64/md5sums and i386/md5sums differ expectk-tk8.3 *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums fgetty: Files amd64/md5sums and i386/md5sums differ fnord: Files amd64/md5sums and i386/md5sums differ freeradius-dbg: Files amd64/md5sums and i386/md5sums differ gcc-3.3-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcc-3.4-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcc-4.1-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcc-4.2-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcc-4.3-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcj-4.1-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcj-4.2-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gcj-4.3-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gftp-common: Files amd64/md5sums and i386/md5sums differ gnat-4.1-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gnat-4.2-base *MUST* be Architecture: all! identical files: amd64/md5sums i386/md5sums powerpc/md5sums gnustep-common: Files amd64/md5sums and i386/md5sums differ gnustep-make-ogo: Files amd64/md5sums and i386/md5sums differ gstreamer0.10-gnonlin-dev: Files amd64/md5sums and i386/md5sums differ
Re: List of packages which should probably be Architecture: all
In gmane.linux.debian.devel.general Raphael Geissert [EMAIL PROTECTED] wrote:
Hello all again,
I just wrote, another, script which downloads the i386 and amd64 'versions'
of the packages listed by the script which checks for empty Build-/Depends
and compares the md5sums (from control.tar.gz) of both packages.
Before I post the results I'd like to clarify that I've noticed that some of
the files which differ from arch i386 to arch amd64 are for example the
compressed Debian package changelog and similar compressed files. Does
anyone has any idea how this could happen? zdiff'ing those files
demonstrates that the files are identical.
[...]
That is gzip storing the current time in the header. I think this test
would be more useful if you ignored /usr/share/{doc,info,man}
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Thu, Jan 10, 2008 at 07:53:03PM -0600, Raphael Geissert wrote: Cyril Brulebois wrote: On 11/01/2008, Raphael Geissert wrote: And here's the list of packages which after comparing the md5sum files show no reason why they aren't arch all: Grub Maintainers [EMAIL PROTECTED] grub Again, there is a very good reason: | /usr/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 | (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), | stripped Camm Maguire [EMAIL PROTECTED] hol88-library So, again, *how* do you find it possible to list this package as MUST be Architecture: all, while it has things like that inside? | … cut … | /usr/lib/hol88-2.02.19940316/Library/pair/basic_ml.o: ELF 32-bit LSB | relocatable, Intel 80386, version 1 (SYSV), not stripped | /usr/lib/hol88-2.02.19940316/Library/pair/both1_ml.o: ELF 32-bit LSB | relocatable, Intel 80386, version 1 (SYSV), not stripped | usr/lib/hol88-2.02.19940316/Library/pair/both2_ml.o: ELF 32-bit LSB | relocatable, Intel 80386, version 1 (SYSV), not stripped … cut … There MUST be something wrong with the package then, how is that i386's and amd64's md5sum are exactly the same? I don't know about hol88-library, but grub builds with -m32 on amd64. Nevertheless, it's still architecture-dependent; it builds different binaries on Linux and the Hurd, and also the grub package should not be in Packages for architectures to which it hasn't been ported. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all again, I just wrote, another, script which downloads the i386 and amd64 'versions' of the packages listed by the script which checks for empty Build-/Depends and compares the md5sums (from control.tar.gz) of both packages. Before I post the results I'd like to clarify that I've noticed that some of the files which differ from arch i386 to arch amd64 are for example the compressed Debian package changelog and similar compressed files. Does anyone has any idea how this could happen? zdiff'ing those files demonstrates that the files are identical. Note that this is the raw output of the script, packages which MUST be arch all (debian-installer is excluded, because of technical reasons) are listed below the list. 2vcard: Files amd64/md5sums and i386/md5sums differ biosquid-dev: Files amd64/md5sums and i386/md5sums differ busybox-static: Files amd64/md5sums and i386/md5sums differ centerim-common: Files amd64/md5sums and i386/md5sums differ Processing cgilib...diff: amd64/md5sums: No such file or directory diff: i386/md5sums: No such file or directory cgilib: chasen-cannadic: Files amd64/md5sums and i386/md5sums differ Processing check... cvm-dev: Files amd64/md5sums and i386/md5sums differ dar-static: Files amd64/md5sums and i386/md5sums differ dballe-common: Files amd64/md5sums and i386/md5sums differ dietlibc-dev: Files amd64/md5sums and i386/md5sums differ drac-dev: Files amd64/md5sums and i386/md5sums differ dvdbackup-dbg: Files amd64/md5sums and i386/md5sums differ e2fsck-static: Files amd64/md5sums and i386/md5sums differ espeak-data: Files amd64/md5sums and i386/md5sums differ etl-dev: Files amd64/md5sums and i386/md5sums differ exim4-dev: Files amd64/md5sums and i386/md5sums differ expectk-tk8.3: Files amd64/md5sums and i386/md5sums differ fgetty: Files amd64/md5sums and i386/md5sums differ fnord: Files amd64/md5sums and i386/md5sums differ freeradius-dbg: Files amd64/md5sums and i386/md5sums differ gcc-3.3-base: Files amd64/md5sums and i386/md5sums differ gcc-3.4-base: Files amd64/md5sums and i386/md5sums differ gcc-4.1-base: Files amd64/md5sums and i386/md5sums differ gcc-4.2-base: Files amd64/md5sums and i386/md5sums differ gcc-4.3-base: Files amd64/md5sums and i386/md5sums differ gcj-4.1-base: Files amd64/md5sums and i386/md5sums differ gcj-4.2-base: Files amd64/md5sums and i386/md5sums differ gftp-common: Files amd64/md5sums and i386/md5sums differ gnat-4.1-base: Files amd64/md5sums and i386/md5sums differ gnat-4.2-base: Files amd64/md5sums and i386/md5sums differ gnu-efi: Files amd64/md5sums and i386/md5sums differ gnustep-common: Files amd64/md5sums and i386/md5sums differ gnustep-make-ogo: Files amd64/md5sums and i386/md5sums differ grub _MUST_ be Architecture: all! identical files: amd64/md5sums i386/md5sums grub-invaders: Files amd64/md5sums and i386/md5sums differ gstreamer0.10-gnonlin-dev: Files amd64/md5sums and i386/md5sums differ hol88-library _MUST_ be Architecture: all! identical files: amd64/md5sums i386/md5sums icewm-common: Files amd64/md5sums and i386/md5sums differ inn2-dev: Files amd64/md5sums and i386/md5sums differ integrit: Files amd64/md5sums and i386/md5sums differ iproute-dev: Files amd64/md5sums and i386/md5sums differ iptables-dev: Files amd64/md5sums and i386/md5sums differ kadu-dev: Files amd64/md5sums and i386/md5sums differ kannel-dev: Files amd64/md5sums and i386/md5sums differ Processing lde... libacovea-dev: Files amd64/md5sums and i386/md5sums differ libagg-dev: Files amd64/md5sums and i386/md5sums differ libaio1: Files amd64/md5sums and i386/md5sums differ libajax5-dev: Files amd64/md5sums and i386/md5sums differ libantlr-dev: Files amd64/md5sums and i386/md5sums differ libatomic-ops-dev: Files amd64/md5sums and i386/md5sums differ libavahi-common-data: Files amd64/md5sums and i386/md5sums differ libbakery-2.3-common: Files amd64/md5sums and i386/md5sums differ libbitcollider-dev: Files amd64/md5sums and i386/md5sums differ libcegui-mk2-doc: Files amd64/md5sums and i386/md5sums differ libchewing3-data: Files amd64/md5sums and i386/md5sums differ libcnf-dev: Files amd64/md5sums and i386/md5sums differ libcurl3-dbg: Files amd64/md5sums and i386/md5sums differ libcwnn-dev: Files amd64/md5sums and i386/md5sums differ libdaemons-ruby1.8: Files amd64/md5sums and i386/md5sums differ libdballe-bufrex-doc: Files amd64/md5sums and i386/md5sums differ libdballe-core-doc: Files amd64/md5sums and i386/md5sums differ libdballe-db-doc: Files amd64/md5sums and i386/md5sums differ libdballe-msg-doc: Files amd64/md5sums and i386/md5sums differ libdds-dev: Files amd64/md5sums and i386/md5sums differ libdiscover1-pic: Files amd64/md5sums and i386/md5sums differ libdts-dev: Files amd64/md5sums and i386/md5sums differ libdvb-dev: Files amd64/md5sums and i386/md5sums differ libflake-dev: Files amd64/md5sums and i386/md5sums differ libgcj-common: Files amd64/md5sums and i386/md5sums differ libgeomview-dev: Files amd64/md5sums
Re: List of packages which should probably be Architecture: all
On 11/01/2008, Raphael Geissert wrote: Note that this is the raw output of the script, packages which MUST be arch all (debian-installer is excluded, because of technical reasons) are listed below the list. *MUST*, ahah. And here's the list of packages which after comparing the md5sum files show no reason why they aren't arch all: Grub Maintainers [EMAIL PROTECTED] grub Again, there is a very good reason: | /usr/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), stripped Camm Maguire [EMAIL PROTECTED] hol88-library So, again, *how* do you find it possible to list this package as MUST be Architecture: all, while it has things like that inside? | … cut … | /usr/lib/hol88-2.02.19940316/Library/pair/basic_ml.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped | /usr/lib/hol88-2.02.19940316/Library/pair/both1_ml.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped | usr/lib/hol88-2.02.19940316/Library/pair/both2_ml.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped | … cut … Robert Millan [EMAIL PROTECTED] grub (U) Again… Masahito Omote [EMAIL PROTECTED] libuim-data Sounds reasonable. Otavio Salvador [EMAIL PROTECTED] grub (U) Jason Thomas [EMAIL PROTECTED] grub (U) Again… As usually, feedback is welcome. Reiterating… -- Cyril Brulebois pgp0QfdF4nUBI.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
Cyril Brulebois wrote: On 11/01/2008, Raphael Geissert wrote: Note that this is the raw output of the script, packages which MUST be arch all (debian-installer is excluded, because of technical reasons) are listed below the list. *MUST*, ahah. Sorry, that is more like a s/MUST/REALLY SHOULD (strong should? :) And here's the list of packages which after comparing the md5sum files show no reason why they aren't arch all: Grub Maintainers [EMAIL PROTECTED] grub Again, there is a very good reason: | /usr/sbin/grub: ELF 32-bit LSB executable, Intel 80386, version 1 | (SYSV), for GNU/Linux 2.6.1, dynamically linked (uses shared libs), | stripped Camm Maguire [EMAIL PROTECTED] hol88-library So, again, *how* do you find it possible to list this package as MUST be Architecture: all, while it has things like that inside? | … cut … | /usr/lib/hol88-2.02.19940316/Library/pair/basic_ml.o: ELF 32-bit LSB | relocatable, Intel 80386, version 1 (SYSV), not stripped | /usr/lib/hol88-2.02.19940316/Library/pair/both1_ml.o: ELF 32-bit LSB | relocatable, Intel 80386, version 1 (SYSV), not stripped | usr/lib/hol88-2.02.19940316/Library/pair/both2_ml.o: ELF 32-bit LSB | relocatable, Intel 80386, version 1 (SYSV), not stripped … cut … There MUST be something wrong with the package then, how is that i386's and amd64's md5sum are exactly the same? Robert Millan [EMAIL PROTECTED] grub (U) Again… Did you notice the (U)? ;) Masahito Omote [EMAIL PROTECTED] libuim-data Sounds reasonable. Otavio Salvador [EMAIL PROTECTED] grub (U) Jason Thomas [EMAIL PROTECTED] grub (U) Again… As usually, feedback is welcome. Reiterating… Should probably compare i386 and something like armel next time. I'm, again, sorry for those false positives (didn't expect them by comparing md5sums of two different architectures). Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 11/01/2008, Raphael Geissert wrote:
There MUST be something wrong with the package then, how is that
i386's and amd64's md5sum are exactly the same?
I don't see this that way. There *might* be a problem in your script or
so.
,---[ let's check ]---
| [EMAIL PROTECTED]:/tmp/grub$ wget -q
http://ftp.de.debian.org/debian/pool/main/g/grub/grub_0.97-29_i386.deb
| [EMAIL PROTECTED]:/tmp/grub$ wget -q
http://ftp.de.debian.org/debian/pool/main/g/grub/grub_0.97-29_amd64.deb
| [EMAIL PROTECTED]:/tmp/grub$ for i in amd64 i386; do ar x grub_0.97-29_$i.deb
control.tar.gz; tar xfz control.tar.gz; mv control control.$i; mv md5sums
md5sums.$i; rm control.tar.gz; done
| [EMAIL PROTECTED]:/tmp/grub$ diff -u md5sums.* | diffstat
| md5sums.i386 | 72
+--
| 1 file changed, 36 insertions(+), 36 deletions(-)
`---
Note that the i386 package has the following additional Depends line,
compared to the amd64 one.
| +Depends: libc6 (= 2.5-5), libncurses5 (= 5.4-5)
I guess your scripts are somehow assuming that if one has an empty
Depends line, the other has an empty line as well, or something similar.
Back to grub: Unfortunately, there's no amd64 log (source upload along
with the built binaries…), but it might be that ${shlibs:Depends}
weren't computed correctly or so, so that the Depends line was left
empty.
Indeed, checking a cowbuilder build log:
| dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
In an amd64 chroot, looking closer:
| $ file debian/grub/usr/bin/mbchk
| usr/bin/mbchk:ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.8, statically linked, stripped
That's also the case for the other binaries, so it results apparently
(I'm no grub maintainer at all) correctly in an empty Depends: line.
Did you notice the (U)? ;)
Yes. I actually expected somehow that you could have noticed that it was
about “grub”.
I'm, again, sorry for those false positives (didn't expect them by
comparing md5sums of two different architectures).
I'm not blaming because of false positives. I'd expect more common
sense. Either grub is architecture-dependent, being a low-level stuff,
probably written in C (I know, that might sound like a cliché, but…), or
it is just made out of supercowpowered architecture-independent shell
scripts, but then one might wonder a bit. Seen where it belongs in a
boot sequence?
Reviewing such a short list takes some minutes (to compare with the time
you spent on setting up these scripts), using the main measure when it
comes to being “Architecture: all” or “Architecture: any”: its *content*
(but you know that, I've been repeating this from the very beginning).
--
Cyril Brulebois
pgpxo71P5zfDc.pgp
Description: PGP signature
Re: List of packages which should probably be Architecture: all
Hi, On Thu, Jan 10, 2008 at 07:18:28PM -0600, Raphael Geissert wrote: Before I post the results I'd like to clarify that I've noticed that some of the files which differ from arch i386 to arch amd64 are for example the compressed Debian package changelog and similar compressed files. Does anyone has any idea how this could happen? zdiff'ing those files demonstrates that the files are identical. Just have a look at gzip headers and you will understand that it stores the modification timestamp of the original file into the compressed file. The file utility will show you that. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Debian Maintainer `- Unix Sys Net Admin signature.asc Description: Digital signature
Re: List of packages which should probably be Architecture: all
* Raphael Geissert [EMAIL PROTECTED] [2008-01-02 13:17]: Rafael Laboissiere [EMAIL PROTECTED] tess (U) Fixed: http://lists.debian.org/debian-devel-changes/2008/01/msg00693.html Thanks for spotting this problem. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hi On Wed, 02 Jan 2008 13:58:24 -0600 Raphael Geissert [EMAIL PROTECTED] wrote: Michal Čihař [EMAIL PROTECTED] libgammu3 Eh? $ apt-cache show libgammu3 | grep ^Dep Depends: libbluetooth2 (= 3.0), libc6 (= 2.7-1), libgammu-common (= 1.17.0-1) -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: List of packages which should probably be Architecture: all
Michal Čihař wrote: Hi On Wed, 02 Jan 2008 13:58:24 -0600 Raphael Geissert [EMAIL PROTECTED] wrote: Michal Čihař [EMAIL PROTECTED] libgammu3 Eh? Seems like it is one of the very few false positives of the old script. The fresh reports using grep-ctrl instead of a lot of grep's (which seem to have caused some false positives) can be found at: http://alioth.debian.org/~atomo64-guest/should-be-arch-all.txt http://alioth.debian.org/~atomo64-guest/should-be-arch-all.by-maint.txt Both updated weekly $ apt-cache show libgammu3 | grep ^Dep Depends: libbluetooth2 (= 3.0), libc6 (= 2.7-1), libgammu-common (= 1.17.0-1) Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:58:24PM -0600, Raphael Geissert wrote: clips-common Fixed now, I'm going to upload a new version (6.24-2) making it arch: all Javier signature.asc Description: Digital signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008, Raphael Geissert wrote: gstreamer0.10-gnonlin-dev Fixed in SVN (useless package dropped). libavahi-common-data (U) Ships a GDBM file which is arch-dep; shouldn't ship it in /usr/share though. libdvb-dev (U) Only ships static libs; no idea why. system-tools-backends-dev (U) Fixed in SVN; shipped an arch-indep pkg-config file which should be moved from /usr/share to /usr/lib. vala-doc (U) I filed a bug on this one (I'm mostly sponsor-uploader). -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello, On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Michael Koch [EMAIL PROTECTED] antlr (U) False positive. libantlr-dev includes two static libraries and may not be arch:any therefor. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Thu, Jan 03, 2008 at 10:51:16AM +0100, Loïc Minier wrote: On Wed, Jan 02, 2008, Raphael Geissert wrote: libavahi-common-data (U) Ships a GDBM file which is arch-dep; shouldn't ship it in /usr/share though. Are those really arch-specific? That's really crap design. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Thu, Jan 03, 2008 at 09:50:48AM +1100, Brian May wrote: Raphael == Raphael Geissert [EMAIL PROTECTED] writes: Raphael Brian May [EMAIL PROTECTED] Raphael dar-static Raphael Theodore Y. Ts'o [EMAIL PROTECTED] Raphael e2fsck-static Both of these (and maybe others) are false positives. Which would be caught if the test actually say, used the file command for any binary that had files installed in a .../bin directory or .../lib directory. BTW, I recently got a complaint from someone who was still using a 2.4 Woody system, and had been using e2fsck-static as a way of getting the latest e2fsprogs fixups for e2fsck, given that the woody backports effort had stopped a while ago. Apparently the latest glibc uses thread local storage in its locale code, so even linking statically against glibc will result in a binary that can't be used on a 2.4 kernel. Because I was a nice guy, I hacked up e2fsck-static to build against dietlibc instead, so it would work on ancient systems. Dropped the size of the binary from over a megabyte to about 330k, a savings of two-thirds - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, Jan 03, 2008 at 10:51:16AM +0100, Loïc Minier wrote: On Wed, Jan 02, 2008, Raphael Geissert wrote: libavahi-common-data (U) Ships a GDBM file which is arch-dep; shouldn't ship it in /usr/share though. Are those really arch-specific? That's really crap design. Yeah, gdbm is really a crap design. perldoc AnyDBM_File is interesting on this score: DBM Comparisons Here's a partial table of features the different packages offer: odbmndbmsdbmgdbmbsd-db -- Linkage comes w/ perl yes yes yes yes yes Src comes w/ perl no no yes no no Comes w/ many unix os yes yes[0] no no no Builds ok on !unix ? ? yes yes ? Code Size ? ? small big big Database Size ? ? small big?ok[1] Speed ? ? slowok fast FTPable no no yes yes yes Easy to build N/A N/A yes yes ok[2] Size limits 1k 4k 1k[3] nonenone Byte-order independent no no no no yes Licensing restrictions ? ? no yes no [0] on mixed universe machines, may be in the bsd compat library, which is often shunned. [1] Can be trimmed if you compile for one access method. [2] See DB_File. Requires symbolic links. [3] By default, but can be redefined. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: List of packages which should probably be Architecture: all
James Vega wrote:
grep-dctrl ! -FDepends -e '.' -a ! -FPre-Depends -e '.' \
-a ! -FArchitecture all -n -sPackage binary-i386_Packages
This approach is better and far faster than mine, diff'ing the results of
both methods show four less binaries (which all of them are false positives
using my method).
I just added a weekly cronjob in my alioth account to regenerate the lists
(based on the sid/{main,contrib,non-free}/binary-i386/Packages) which are
available at:
http://alioth.debian.org/~atomo64-guest/should-be-arch-all.txt
Containing only the package names
http://alioth.debian.org/~atomo64-guest/should-be-arch-all.by-maint.txt
Same as above but ordered by maintainer (no Uploaders available because
Packages doesn't provide it).
Cheers,
--
Atomo64 - Raphael
Please avoid sending me Word, PowerPoint or Excel attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Raphael Geissert [EMAIL PROTECTED] writes: Brendan O'Dea [EMAIL PROTECTED] perl-base That's a false positive. Please also take a look at Pre-Depends. Or simply let off of this effort, the number of false positives is enormous. Marc -- BOFH #343: The ATM board has run out of 10 pound notes. We are having a whip round to refill it, care to contribute ? pgpCYDrBtOwKa.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
Marc 'HE' Brockschmidt wrote: Raphael Geissert [EMAIL PROTECTED] writes: Brendan O'Dea [EMAIL PROTECTED] perl-base That's a false positive. Please also take a look at Pre-Depends. Or simply let off of this effort, the number of false positives is enormous. The automated listings already use grep-ctrl also checking for Pre-Depends, both actions reducing the number of false positives. I'm posting again the links: http://alioth.debian.org/~atomo64-guest/should-be-arch-all.txt http://alioth.debian.org/~atomo64-guest/should-be-arch-all.by-maint.txt As I already said on one of my messages I'll do further analysis, but meanwhile there's a preview of the packages that will probably be listed even after a deeper/better check. Marc Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hi, On Thu, 2008-01-03 at 10:51:16 +0100, Loïc Minier wrote: On Wed, Jan 02, 2008, Raphael Geissert wrote: libdvb-dev (U) Only ships static libs; no idea why. That's due to #218387, #226985 and #359697. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Raphael Geissert wrote: Hello all, Maw. I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. Hm, what about checking their *content*? What about listing *binary* packages? Cheers, -- Cyril Brulebois pgpLZXls1co1w.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. Your list seems to contain alot of packages that do have a Depends field. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello Kurt, Kurt Roeckx wrote: On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. Your list seems to contain alot of packages that do have a Depends field. Like which one? I used a lot of grepping so maybe something was left in. Kurt Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Clint Adams [EMAIL PROTECTED] db (U) zsh My first suggestion is to list binary packages instead of source. Then I could say that db4.6-doc is already arch:all and that zsh-static is a false positive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Raphael Geissert wrote: Your list seems to contain alot of packages that do have a Depends field. Like which one? I used a lot of grepping so maybe something was left in. Take any random package, let's say icecc: $ apt-cache show icecc|grep ^Depends: Depends: libc6 (= 2.6-1), libgcc1 (= 1:4.2-20070516), libstdc++6 (= 4.2-20070516), debconf (= 0.5) | debconf-2.0, adduser, lsb-base A quick look at its content should also convince you that having binary objects under /usr/bin, /usr/lib, /usr/sbin isn't really a reason to ask for making it become an Architecture: all package… -- Cyril Brulebois pgp9FgKHmhFLe.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
My first suggestion is to list binary packages instead of source. What about listing *binary* packages? That would be the doing of dd-list alone, it seems. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - ¿Quién es Abel, quién es Caín? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello Cyril, Cyril Brulebois wrote: Hm, what about checking their *content*? What about listing *binary* packages? Forgot to mention that, based on the binary-amd64 Packages file of the main, contrib and non-free sections. I didn't check the content of the packages because that's something linda/lintian should do, this is just a simple/quick list of packages and as I said it may contain some false positives (although there's usually a reason/bug causing the package to be listed). Cheers, Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 07:17:24PM +, Raphael Geissert wrote: maximilian attems [EMAIL PROTECTED] klibc linux-2.6 (U) OMG, I wish we knew about this before, we clearly would have saved a _lot_ of buildd time. Seriously, did you even _read_ the list you just submitted ? at least 66% of it is obviously wrong. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyd0O2NwTxk.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just to clarify to everybody, the list was screwed up by dd-list (my bad, didn't see the '-b' option part). Thanks to Adeodato for pointing that out. So, here's the list of binary packages (attachment is dd-list -u again). Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim-common Loic Dachary (OuoU) [EMAIL PROTECTED] libunittest++0 (U) Peter De Schrijver (p2) [EMAIL PROTECTED] openwince-include Johan Euphrosine (proppy) [EMAIL PROTECTED] libunittest++0 Clint Adams [EMAIL PROTECTED] libdb4.6-dbg (U) zsh-dev Martin Albisetti [EMAIL PROTECTED] 2vcard Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) Stuart R. Anderson [EMAIL PROTECTED] lsb-build-base2 lsb-build-base3 Domenico Andreoli [EMAIL PROTECTED] libcurl3-dbg Kumar Appaiah [EMAIL PROTECTED] vala-doc (U) maximilian attems [EMAIL PROTECTED] libklibc linux-headers-2.6.23-1-common (U) linux-libc-dev (U) Jeff Bailey [EMAIL PROTECTED] libklibc (U) Michael Banck [EMAIL PROTECTED] opensync-plugin-palm-dev Andreas Barth [EMAIL PROTECTED] iproute-dev (U) iproute-doc (U) Douglas Bates [EMAIL PROTECTED] r-mathlib (U) Bradley Bell [EMAIL PROTECTED] libbakery-2.3-common Christoph Berg [EMAIL PROTECTED] libdds-dev CJ van den Berg [EMAIL PROTECTED] libpulse-browse0-dbg Michael Biebl [EMAIL PROTECTED] tracker-dbg Bastian Blank [EMAIL PROTECTED] busybox-static (U) linux-headers-2.6.23-1-common (U) linux-libc-dev (U) Eduard Bloch [EMAIL PROTECTED] icewm-common W. Borgert [EMAIL PROTECTED] libomnievents-dev Fathi Boudra [EMAIL PROTECTED] libicecc-dev (U) Joachim Breitner [EMAIL PROTECTED] xaralx-examples Ludovic Brenta [EMAIL PROTECTED] gnat-4.1-base (U) gnat-4.2-base (U) Marc 'HE' Brockschmidt [EMAIL PROTECTED] libgnomecanvas2-0 (U) Rob Browning [EMAIL PROTECTED] libqthreads-12 Cyril Brulebois [EMAIL PROTECTED] etl-dev (U) Ross Burton [EMAIL PROTECTED] libxnee-dev Petr Cech [EMAIL PROTECTED] lde Hubert Chathi [EMAIL PROTECTED] gnustep-common (U) gnustep-make-ogo (U) Kanru Chen [EMAIL PROTECTED] libchewing3-data Patryk Cisek [EMAIL PROTECTED] kadu-dev Robert Collins [EMAIL PROTECTED] opensync-plugin-palm-dev (U) Arnaud Cornet [EMAIL PROTECTED] ratbox-services-common Nigel Croxon [EMAIL PROTECTED] gnu-efi Marco d'Itri [EMAIL PROTECTED] inn2-dev Joost Yervante Damad [EMAIL PROTECTED] libflake-dev (U) Terry Dawson [EMAIL PROTECTED] libhamlib-doc (U) Debian Berkeley DB Maintainers [EMAIL PROTECTED] libdb4.6-dbg Debian EMBOSS Packaging Team [EMAIL PROTECTED] libajax5-dev libnucleus5-dev Debian GCC Maintainers [EMAIL PROTECTED] gcc-3.3-base gcc-3.4-base gcc-4.1-base gcc-4.2-base gcj-4.1-base gcj-4.2-base gnat-4.1-base gnat-4.2-base libgcj-common Debian GNOME Maintainers [EMAIL PROTECTED] libgnomecanvas2-0 (U) system-tools-backends-dev (U) Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-common gnustep-make-ogo Debian Install System Team [EMAIL PROTECTED] busybox-static debian-installer libdiscover1-pic os-prober Debian Java Maintainers [EMAIL PROTECTED] libantlr-dev Debian JED Group [EMAIL PROTECTED] slang-tess Debian KDE Extras Team [EMAIL PROTECTED] libicecc-dev Debian Kernel Team [EMAIL PROTECTED] linux-headers-2.6.23-1-common linux-libc-dev Debian multimedia packages maintainers [EMAIL PROTECTED] libdts-dev libdvb-dev liblivemedia-dev Debian Multimedia Team [EMAIL PROTECTED] libflake-dev Debian OpenOffice Team [EMAIL PROTECTED] libmythes-dev openoffice.org-dbg Debian Qt/KDE Maintainers [EMAIL PROTECTED] libqt3-headers Debian Ruby Extras Maintainers [EMAIL PROTECTED] libdaemons-ruby1.8 (U) Debian Scientific Computing Team [EMAIL PROTECTED] libnetgen-dev Debian Synfig Maintainers [EMAIL PROTECTED] etl-dev Debian TeX Maintainers [EMAIL PROTECTED] texlive-base-bin-doc texlive-metapost-doc Debian VDR Team [EMAIL PROTECTED] libmdsp-dev Debian VoIP Team [EMAIL PROTECTED] libsrtp1-dev Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-dev-tools XCB Developers [EMAIL PROTECTED] libpthread-stubs0 Scott M. Dier [EMAIL PROTECTED] libbitcollider-dev Yann Dirson [EMAIL PROTECTED] memtest86 memtest86+ Sebastian Dröge [EMAIL PROTECTED] libavahi-common-data (U) libgnomecanvas2-0 (U) vala-doc (U) Paul Dwerryhouse [EMAIL PROTECTED] kannel-dev Dirk Eddelbuettel [EMAIL PROTECTED] libtclap-dev r-mathlib Free Ekanayaka [EMAIL PROTECTED] libflake-dev (U) Rene Engelhard [EMAIL PROTECTED] liblpsolve55-dev (U) libmythes-dev (U) openoffice.org-dbg (U) Exim4 Maintainers [EMAIL PROTECTED] exim4-dev Fabian Fagerholm [EMAIL PROTECTED] etl-dev (U) Andreas Fester [EMAIL PROTECTED] libqcad0-dev Andreas Franzen [EMAIL PROTECTED] pgapack Bdale Garbee [EMAIL
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:38:32PM -0600, Raphael Geissert wrote: Hello Kurt, Kurt Roeckx wrote: On Wed, Jan 02, 2008 at 01:17:24PM -0600, Raphael Geissert wrote: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. Your list seems to contain alot of packages that do have a Depends field. Like which one? I used a lot of grepping so maybe something was left in. As already pointed out by some others, you should list the binary packages instead of the source packages. It's rather confusing like this. Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim That should be centerim-common Loic Dachary (OuoU) [EMAIL PROTECTED] unittest++ (U) libunittest++0 Johan Euphrosine (proppy) [EMAIL PROTECTED] unittest++ libunittest++0 Russ Allbery [EMAIL PROTECTED] gss (U) libgss-dbg, false positive shishi (U) shishi-dbg, false positive Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Interesting idea, though so few packages lack dependencies that it won't catch much. Perhaps grepping for package that don't depend on any shared libraries would catch more? Raphael Geissert wrote: maximilian attems [EMAIL PROTECTED] klibc linux-2.6 (U) heh Andreas Barth [EMAIL PROTECTED] iproute (U) Has dependencies. busybox depends on libc6 debian-installer Arch all so that d-i boot images will autobuild. discover1 depends on libc6 os-prober Contains architecture-dependent shell scripts, like many other d-i udebs. -- see shy jo
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Raphael Geissert wrote: Forgot to mention that, based on the binary-amd64 Packages file of the main, contrib and non-free sections. I didn't check the content of the packages because that's something linda/lintian should do Wondering why, I asked what they were supposed to catch: 20:51:10 [ KiBi] Atomo64: What are linda/lintian supposed to catch? 20:51:49 [ KiBi] That an Architecture: any package rightfully contains architecture-dependent data? 20:51:57 [ Atomo64] KiBi: !arch: all packages not containing any arch-dependent file You might have missed the point, trying again: your list contains plenty of “Architecture: any” packages that are *rightfully* “any” because they *do* contain architecture-dependant stuff (see e.g. icecc as already pointed out). this is just a simple/quick list of packages and as I said it may contain some false positives (although there's usually a reason/bug causing the package to be listed). Maybe there's rather a bug in your process. Instead of speaking of “plenty of greps”, you might want to expose the code / algorithm you used. -- Cyril Brulebois pgpHsdTBsCCaC.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpicoMtNRbk4.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, 02 Jan 2008 13:17:24 -0600, Raphael Geissert [EMAIL PROTECTED] said: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. Maybe you want to make this into a lintian test? [...] Hubert Chathi [EMAIL PROTECTED] gnustep-make (U) This package only contains data files (makefile snippets, shell scripts, etc.), but the contents of the data files vary depending on what architecture it was built on, since it needs to control building for the right environment. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hello Joey, Joey Hess wrote: Interesting idea, though so few packages lack dependencies that it won't catch much. Perhaps grepping for package that don't depend on any shared libraries would catch more? Nice idea, though I'll first wait for everybody to read my last message (Message-ID: [EMAIL PROTECTED]) which contains the 'good' list (I wonder why dd-list goes the source packages way when the ones provided in the input are nothing but binary packages). Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 08:04:44PM +, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... Though after a second thought, -dbg should probably not have empty Depends line. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpS3HNNobS5m.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 01:58:24PM -0600, Raphael Geissert wrote: Just to clarify to everybody, the list was screwed up by dd-list (my bad, didn't see the '-b' option part). Thanks to Adeodato for pointing that out. So, here's the list of binary packages (attachment is dd-list -u again). This list looks alot better, but still seems to contains atleast 1 that have a Depends field: Marc 'HE' Brockschmidt [EMAIL PROTECTED] libgnomecanvas2-0 (U) Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. -- Cyril Brulebois pgp8jGHoiH4cw.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 08:16:21PM +, Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. I agree. My point is, listing packages with an empty Depends: line isn't meaningless. The total lack of data-massaging _is_ a mistake though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprD3GzFg5dK.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 09:11:40PM +0100, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 08:04:44PM +, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... Though after a second thought, -dbg should probably not have empty Depends line. It should even have a = dependency on the binary package that contains the binaries. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll consider your message as sent (won't verify timestamps) before I clarified the situation both by mail and on IRC. Cyril Brulebois wrote: Maybe there's rather a bug in your process. Instead of speaking of “plenty of greps”, you might want to expose the code / algorithm you used. Parts of it are pretty ugly (and the Packages-fetching part isn't there), but I'm attaching it anyway. Cheers, - -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHe/FJYy49rUbZzloRAnsOAJ9vsqqQ3tVJW6mant4W4vNOn0R/IACePp+z gd3VgRJ0FeUZEqDPbZl2ohI= =va4z -END PGP SIGNATURE- should-be-arch-all.sh Description: application/shellscript
Re: List of packages which should probably be Architecture: all
Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. Quoting my self (first message): This is usually bug either because of a missing Depends or because the package should be Architecture: all. Cheers, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Raphael Geissert a écrit : Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. Quoting my self (first message): This is usually bug either because of a missing Depends or because the package should be Architecture: all. I fail to see why. Imagine for example a -dev package providing only .h files, but depending on the architecture. It has to be Architecture: any and does not need to Depends on a package. You really have to look at the contents of the package and verify it does not change between architecture. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Pierre Habouzit [EMAIL PROTECTED] writes: On Wed, Jan 02, 2008 at 08:04:44PM +, Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... Though after a second thought, -dbg should probably not have empty Depends line. Indeed. Fixed in CVS, and I'll file a wishlist lintian bug to remind me or someone to write a check at some point. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Pierre Habouzit wrote: On Wed, Jan 02, 2008 at 07:58:24PM +, Raphael Geissert wrote: Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) rrght... -dbg package without a Depends? that sounds like a bug (please read my first message). Depends: sishi Depends: libgss0 ? -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Hubert Chathi [EMAIL PROTECTED] writes: Maybe you want to make this into a lintian test? The reason not to do a general lintian test is exactly... This package only contains data files (makefile snippets, shell scripts, etc.), but the contents of the data files vary depending on what architecture it was built on, since it needs to control building for the right environment. ...that. It's very hard for lintian to rule out false positives here. Other examples include header files with architecture-specific defines or data types. lintian does already have a few checks in this area for specific types of packages. Another check that would generally be valid would be to flag any package that only installs files in /usr/share but is arch: any. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 03:06:21PM -0500, Hubert Chathi wrote: On Wed, 02 Jan 2008 13:17:24 -0600, Raphael Geissert [EMAIL PROTECTED] said: Hello all, I've written a script which tries to detect packages which should be architecture all based on the fact that they don't contain a Depends field. This is usually bug either because of a missing Depends or because the package should be Architecture: all. Maybe you want to make this into a lintian test? One thing I feel is worth mentioning is that it is more harmful for a package to be mistakenly Architecture: all than mistakenly Architecture: any. The former merely wastes some disk space, while the latter will cause actual broken packages. While the breakage would be obvious in the case of packages containing ELF binaries, in the case of packages like os-prober that include different scripts depending on the build architecture, the breakage would be more subtle and time-consuming: it will simply fail to detect things that should have been detected. In light of this, and that there's no straightforward way I can think of for Lintian to detect this situation given a binary package, I feel that a Lintian test risks prompting inexperienced maintainers to err on the side of incaution and set an incorrect Architecture field. I appreciate the zeal involved in cleaning up those packages which are any when they should be all, but is a Lintian test for this worth the potential breakage? Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Aurelien Jarno wrote: I fail to see why. Imagine for example a -dev package providing only .h files, but depending on the architecture. It has to be Architecture: any and does not need to Depends on a package. I know I'm hidding behind my 'the results may contain many false positives' statement but I'm really aware there are some exceptions (like the one you mentioned or others like kdepim-dbg, as stated by Sune Vuorela, which contain the symbols of several binaries which are distributed in several binary packages). You really have to look at the contents of the package and verify it does not change between architecture. I'll try to do it when I have time and after the archive wide lintian check (on amd64 binary packages only) I talked about in #-qa Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Colin Watson wrote: While the breakage would be obvious in the case of packages containing ELF binaries, […] Not necessarily, one could remember of RC bugs opened for some months due to arch: all packages containing shared objects, and its maintainer wondering what was happening on 64-bit architectures, where 32-bit shared objects were (unsuccessfully) tried to be used. -- Cyril Brulebois pgpmyYrhdOIhc.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 09:39:17PM +0100, Aurelien Jarno wrote: Raphael Geissert a écrit : Cyril Brulebois wrote: On 02/01/2008, Pierre Habouzit wrote: Though after a second thought, -dbg should probably not have empty Depends line. After a third thought, I still fail to see what that has to do with being Architecture: all or any. Quoting my self (first message): This is usually bug either because of a missing Depends or because the package should be Architecture: all. I fail to see why. Imagine for example a -dev package providing only .h files, but depending on the architecture. It has to be Architecture: any and does not need to Depends on a package. Most -dev package do not fall in this category because they have a symlink to the shared library and thus have a Depends. This is probably why it says ussually. Reasons why a -dev package can be arch any: - It contains a static library. - It contains headers that change depending on the arch. Reasons why a -dev can have Depends: - symlink to shared library - The headers file in it use header files from an other library. - The libtool .la or pkg-config .pc files mention other such files. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 02:17:08PM -0600, Raphael Geissert wrote: Parts of it are pretty ugly (and the Packages-fetching part isn't there), but I'm attaching it anyway. Tying together grep-dctrl and dd-list would probably be a cleaner approach. I haven't done a thorough comparison to your list but the results seem to be pretty similar. $ grep-dctrl ! -FDepends -e '.' -a ! -FPre-Depends -e '.' \ -a ! -FArchitecture all -n -sPackage binary-i386_Packages | dd-list -i -u -b Anibal Avelar (Fixxxer) [EMAIL PROTECTED] centerim-common Loic Dachary (OuoU) [EMAIL PROTECTED] libunittest++0 (U) Peter De Schrijver (p2) [EMAIL PROTECTED] openwince-include Johan Euphrosine (proppy) [EMAIL PROTECTED] libunittest++0 Clint Adams [EMAIL PROTECTED] libdb4.6-dbg (U) zsh-dev Martin Albisetti [EMAIL PROTECTED] 2vcard Russ Allbery [EMAIL PROTECTED] libgss-dbg (U) shishi-dbg (U) Stuart R. Anderson [EMAIL PROTECTED] lsb-build-base2 lsb-build-base3 Domenico Andreoli [EMAIL PROTECTED] libcurl3-dbg Kumar Appaiah [EMAIL PROTECTED] vala-doc (U) maximilian attems [EMAIL PROTECTED] libklibc linux-headers-2.6.23-1-common (U) linux-headers-2.6.23-1-common-xen (U) linux-libc-dev (U) Jeff Bailey [EMAIL PROTECTED] gnumach (U) gnumach-dev (U) libklibc (U) Jeff Bailey [EMAIL PROTECTED] oskit (U) Michael Banck [EMAIL PROTECTED] opensync-plugin-palm-dev Andreas Barth [EMAIL PROTECTED] iproute-dev (U) iproute-doc (U) Douglas Bates [EMAIL PROTECTED] r-mathlib (U) Daniel Baumann [EMAIL PROTECTED] lightning Bradley Bell [EMAIL PROTECTED] libbakery-2.3-common Christoph Berg [EMAIL PROTECTED] libdds-dev CJ van den Berg [EMAIL PROTECTED] libpulse-browse0-dbg Michael Biebl [EMAIL PROTECTED] tracker-dbg Bastian Blank [EMAIL PROTECTED] busybox-static (U) linux-headers-2.6.23-1-common (U) linux-headers-2.6.23-1-common-xen (U) linux-libc-dev (U) Eduard Bloch [EMAIL PROTECTED] icewm-common Ed Boraas [EMAIL PROTECTED] oskit W. Borgert [EMAIL PROTECTED] libomnievents-dev Fathi Boudra [EMAIL PROTECTED] libicecc-dev (U) Ludovic Brenta [EMAIL PROTECTED] gnat-4.1-base (U) gnat-4.2-base (U) Marcus Brinkmann [EMAIL PROTECTED] gnumach (U) gnumach-dev (U) Paul Brossier [EMAIL PROTECTED] supercollider-dev Cyril Brulebois [EMAIL PROTECTED] etl-dev (U) Ross Burton [EMAIL PROTECTED] libxnee-dev Petr Cech [EMAIL PROTECTED] lde Hubert Chathi [EMAIL PROTECTED] gnustep-common (U) gnustep-make-ogo (U) Kanru Chen [EMAIL PROTECTED] libchewing3-data Patryk Cisek [EMAIL PROTECTED] kadu-dev Robert Collins [EMAIL PROTECTED] opensync-plugin-palm-dev (U) Arnaud Cornet [EMAIL PROTECTED] ratbox-services-common Nigel Croxon [EMAIL PROTECTED] gnu-efi Marco d'Itri [EMAIL PROTECTED] inn2-dev Joost Yervante Damad [EMAIL PROTECTED] libflake-dev (U) Terry Dawson [EMAIL PROTECTED] libhamlib-doc (U) Debian Berkeley DB Maintainers [EMAIL PROTECTED] libdb4.6-dbg Debian EMBOSS Packaging Team [EMAIL PROTECTED] libajax5-dev libnucleus5-dev Debian GCC Maintainers [EMAIL PROTECTED] gcc-3.3-base gcc-3.4-base gcc-4.1-base gcc-4.2-base gcj-4.1-base gcj-4.2-base gnat-4.1-base gnat-4.2-base libgcj-common Debian GNOME Maintainers [EMAIL PROTECTED] system-tools-backends-dev (U) Debian GNUstep maintainers [EMAIL PROTECTED] gnustep-common gnustep-make-ogo Debian Install System Team [EMAIL PROTECTED] busybox-static debian-installer libdiscover1-pic os-prober Debian Java Maintainers [EMAIL PROTECTED] libantlr-dev Debian JED Group [EMAIL PROTECTED] slang-tess Debian KDE Extras Team [EMAIL PROTECTED] libicecc-dev Debian Kernel Team [EMAIL PROTECTED] linux-headers-2.6.23-1-common linux-headers-2.6.23-1-common-xen linux-libc-dev Debian multimedia packages maintainers [EMAIL PROTECTED] libdts-dev libdvb-dev liblivemedia-dev Debian Multimedia Team [EMAIL PROTECTED] libflake-dev Debian OpenOffice Team [EMAIL PROTECTED] libmythes-dev openoffice.org-dbg Debian Qt/KDE Maintainers [EMAIL PROTECTED] libqt3-headers Debian Ruby Extras Maintainers [EMAIL PROTECTED] libdaemons-ruby1.8 (U) Debian Scientific Computing Team [EMAIL PROTECTED] libnetgen-dev Debian Synfig Maintainers [EMAIL PROTECTED] etl-dev Debian TeX Maintainers [EMAIL PROTECTED] texlive-base-bin-doc texlive-metapost-doc Debian VDR Team [EMAIL PROTECTED] libmdsp-dev Debian VoIP Team [EMAIL PROTECTED] libsrtp1-dev Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-dev-tools XCB Developers [EMAIL PROTECTED] libpthread-stubs0 Scott M. Dier [EMAIL PROTECTED] libbitcollider-dev Yann Dirson [EMAIL PROTECTED] memtest86 memtest86+ Sebastian Dröge [EMAIL PROTECTED] libavahi-common-data (U) vala-doc (U) Paul Dwerryhouse [EMAIL PROTECTED] kannel-dev Dirk Eddelbuettel [EMAIL PROTECTED] libtclap-dev
Re: List of packages which should probably be Architecture: all
Raphael Geissert schrieb: Just to clarify to everybody, the list was screwed up by dd-list (my bad, didn't see the '-b' option part). Thanks to Adeodato for pointing that out. So, here's the list of binary packages (attachment is dd-list -u again). Michael Biebl [EMAIL PROTECTED] tracker-dbg Currently tracker-dbg holds the debugging symbols for the binary packages: tracker, tracker-search-tool, libtrackerclient0 and libtracker-gtk0. I didn't want to bloat the archive unnecessarily and add a separate -dbg package for each binary package. Now, adding a Depends on all those 4 binary packages in tracker-dbg seems wrong to me. I don't want to force people to install tracker-search-tool if they only want to debug tracker. I guess this is a quite common problem. So, what's the proper solution to that? Cluttering the archive with a load of -dbg packages or leave it as is? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Re: List of packages which should probably be Architecture: all
On 02/01/2008, Michael Biebl wrote: Now, adding a Depends on all those 4 binary packages in tracker-dbg seems wrong to me. I don't want to force people to install tracker-search-tool if they only want to debug tracker. What about being a bit more subtle and play around with Recommends: (or maybe even Suggests:)? By using e.g. Recommends: you ensure every package is installed in the normal/default/whatever_you_call_it case, but still leave the possibility to the user to only install what s/he really needs. Cheers, -- Cyril Brulebois pgpizM98FJIqT.pgp Description: PGP signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 10:18:46PM +0100, Michael Biebl wrote: So, what's the proper solution to that? Cluttering the archive with a load of -dbg packages or leave it as is? The solution I took for the Vim packages was to have ORed Depends on all of the binary packages that the -dbg package contains debugging symbols for. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: List of packages which should probably be Architecture: all
On Wednesday 02 January 2008 22:18, Michael Biebl wrote:
Raphael Geissert schrieb:
Michael Biebl [EMAIL PROTECTED]
tracker-dbg
Currently tracker-dbg holds the debugging symbols for the binary
packages: tracker, tracker-search-tool, libtrackerclient0 and
libtracker-gtk0.
I didn't want to bloat the archive unnecessarily and add a separate -dbg
package for each binary package.
Now, adding a Depends on all those 4 binary packages in tracker-dbg
seems wrong to me. I don't want to force people to install
tracker-search-tool if they only want to debug tracker.
I guess this is a quite common problem.
So, what's the proper solution to that? Cluttering the archive with a
load of -dbg packages or leave it as is?
How about using alternative dependencies:
Package: tracker-dbg
Depends: tracker (= ${binary:Version}) |
tracker-search-tool (= ${binary:Version}) |
libtrackerclient0 (= ${binary:Version}) |
libtracker-gtk0 (= ${binary:Version})
Cheers,
--
Frank S. Thomas [EMAIL PROTECTED] PGP public key ID: 0xDC426429
Debian Developerfinger fst/[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
Re: List of packages which should probably be Architecture: all
Hi, On Wed, 2008-01-02 at 16:32:48 -0500, James Vega wrote: On Wed, Jan 02, 2008 at 02:17:08PM -0600, Raphael Geissert wrote: Parts of it are pretty ugly (and the Packages-fetching part isn't there), but I'm attaching it anyway. Tying together grep-dctrl and dd-list would probably be a cleaner approach. I haven't done a thorough comparison to your list but the results seem to be pretty similar. $ grep-dctrl ! -FDepends -e '.' -a ! -FPre-Depends -e '.' \ -a ! -FArchitecture all -n -sPackage binary-i386_Packages | dd-list -i -u -b Guillem Jover [EMAIL PROTECTED] gnumach (U) A kernel image (false positive). gnumach-dev (U) Arch specific header files (false positive). libaio1 Syscall stubs, does not use glibc (false positive, has already a shared-lib-without-dependency-information lintian override). regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List of packages which should probably be Architecture: all
Raphael == Raphael Geissert [EMAIL PROTECTED] writes: Raphael Brian May [EMAIL PROTECTED] Raphael dar-static Raphael Theodore Y. Ts'o [EMAIL PROTECTED] Raphael e2fsck-static Both of these (and maybe others) are false positives. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
