Bug#776877: uses ill-defined architecture any-amd64
Looks OK in experimental : https://buildd.debian.org/status/package.php?p=libjpeg-turbosuite=experimental On February 2, 2015 10:20:29 PM GMT+01:00, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote: Hi Ondrej, i think it was related to a nasm problem on 32bit system back in the early turbo days, probably this one [1]. My guess is that we could try to drop nasm's architecture limitation completely from BD, presuming that latest nasm versions handle things well by now. Mike [1] http://sourceforge.net/p/libjpeg-turbo/bugs/20/ -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de - Original message - Hi Mike, do you have an idea, why nasm is limited just to some architectures? It looks like it's available on all release Debian architectures: https://packages.debian.org/unstable/nasm So it seems there's no reason to have the limit in the place at all. Cheers, Ondrej On Mon, Feb 2, 2015, at 20:50, Helmut Grohne wrote: Source: libjpeg-turbo Version: 1:1.3.1-11 User: helm...@debian.org Usertags: rebootstrap Control: block -1 by 748936 libjpeg-progs uses the ill-defined architecture wildcard any-amd64 in its Build-Depends. apt and dpkg do not agree on its meaning (for details see #748936). For instance on apt would not treat x32 as any-amd64, but dpkg would. This causes x32 builds of libjpeg-turbo to fail at dpkg-checkbuilddeps when installing build-depends with apt-get build-dep. Please use something other than any-amd64. Maybe amd64 kfreebsd-amd64? I mark 748936 as a blocker of this bug to keep track of the instances of the issue. Helmut -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#776877: uses ill-defined architecture any-amd64
Source: libjpeg-turbo Version: 1:1.3.1-11 User: helm...@debian.org Usertags: rebootstrap Control: block -1 by 748936 libjpeg-progs uses the ill-defined architecture wildcard any-amd64 in its Build-Depends. apt and dpkg do not agree on its meaning (for details see #748936). For instance on apt would not treat x32 as any-amd64, but dpkg would. This causes x32 builds of libjpeg-turbo to fail at dpkg-checkbuilddeps when installing build-depends with apt-get build-dep. Please use something other than any-amd64. Maybe amd64 kfreebsd-amd64? I mark 748936 as a blocker of this bug to keep track of the instances of the issue. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776877: uses ill-defined architecture any-amd64
Hi Mike, do you have an idea, why nasm is limited just to some architectures? It looks like it's available on all release Debian architectures: https://packages.debian.org/unstable/nasm So it seems there's no reason to have the limit in the place at all. Cheers, Ondrej On Mon, Feb 2, 2015, at 20:50, Helmut Grohne wrote: Source: libjpeg-turbo Version: 1:1.3.1-11 User: helm...@debian.org Usertags: rebootstrap Control: block -1 by 748936 libjpeg-progs uses the ill-defined architecture wildcard any-amd64 in its Build-Depends. apt and dpkg do not agree on its meaning (for details see #748936). For instance on apt would not treat x32 as any-amd64, but dpkg would. This causes x32 builds of libjpeg-turbo to fail at dpkg-checkbuilddeps when installing build-depends with apt-get build-dep. Please use something other than any-amd64. Maybe amd64 kfreebsd-amd64? I mark 748936 as a blocker of this bug to keep track of the instances of the issue. Helmut -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776877: uses ill-defined architecture any-amd64
Hi Ondrej, i think it was related to a nasm problem on 32bit system back in the early turbo days, probably this one [1]. My guess is that we could try to drop nasm's architecture limitation completely from BD, presuming that latest nasm versions handle things well by now. Mike [1] http://sourceforge.net/p/libjpeg-turbo/bugs/20/ -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de - Original message - Hi Mike, do you have an idea, why nasm is limited just to some architectures? It looks like it's available on all release Debian architectures: https://packages.debian.org/unstable/nasm So it seems there's no reason to have the limit in the place at all. Cheers, Ondrej On Mon, Feb 2, 2015, at 20:50, Helmut Grohne wrote: Source: libjpeg-turbo Version: 1:1.3.1-11 User: helm...@debian.org Usertags: rebootstrap Control: block -1 by 748936 libjpeg-progs uses the ill-defined architecture wildcard any-amd64 in its Build-Depends. apt and dpkg do not agree on its meaning (for details see #748936). For instance on apt would not treat x32 as any-amd64, but dpkg would. This causes x32 builds of libjpeg-turbo to fail at dpkg-checkbuilddeps when installing build-depends with apt-get build-dep. Please use something other than any-amd64. Maybe amd64 kfreebsd-amd64? I mark 748936 as a blocker of this bug to keep track of the instances of the issue. Helmut -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776877: uses ill-defined architecture any-amd64
Indeed! Mike On Mo 02 Feb 2015 23:09:52 CET, Ondřej Surý wrote: Looks OK in experimental : https://buildd.debian.org/status/package.php?p=libjpeg-turbosuite=experimental On February 2, 2015 10:20:29 PM GMT+01:00, Mike Gabriel mike.gabr...@das-netzwerkteam.de wrote: Hi Ondrej, i think it was related to a nasm problem on 32bit system back in the early turbo days, probably this one [1]. My guess is that we could try to drop nasm's architecture limitation completely from BD, presuming that latest nasm versions handle things well by now. Mike [1] http://sourceforge.net/p/libjpeg-turbo/bugs/20/ -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de - Original message - Hi Mike, do you have an idea, why nasm is limited just to some architectures? It looks like it's available on all release Debian architectures: https://packages.debian.org/unstable/nasm So it seems there's no reason to have the limit in the place at all. Cheers, Ondrej On Mon, Feb 2, 2015, at 20:50, Helmut Grohne wrote: Source: libjpeg-turbo Version: 1:1.3.1-11 User: helm...@debian.org Usertags: rebootstrap Control: block -1 by 748936 libjpeg-progs uses the ill-defined architecture wildcard any-amd64 in its Build-Depends. apt and dpkg do not agree on its meaning (for details see #748936). For instance on apt would not treat x32 as any-amd64, but dpkg would. This causes x32 builds of libjpeg-turbo to fail at dpkg-checkbuilddeps when installing build-depends with apt-get build-dep. Please use something other than any-amd64. Maybe amd64 kfreebsd-amd64? I mark 748936 as a blocker of this bug to keep track of the instances of the issue. Helmut -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpuJiBatdGVF.pgp Description: Digitale PGP-Signatur
