Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Fri, Feb 06, 2015 at 10:32:15AM +, Dimitri John Ledkov wrote: > I thing ultimately we do want to drop icu-config. That would have to > be a mass-bugfile "icu-config is to be dropped, which will make your > package FTBFS", followed on by patches / MUs / NMUs, followed by > dropping icu-config -> RC bugs, migration complete. Yeah, we observed that we agree on the long term vision already. > An interim solution could be to split icu-config binary into it's own > M-A:nothing package, but imho that's too late for jessie, and makes > not much sense for jessie+1 given that we would drop that. Well, let me further that thought a bit. Packages that use icu-config, do so by Build-Depending on libicu-dev, so libicu-dev would have to depend on the that new package. Since that new package is M-A:no (it's neither "none" nor "nothing" but "no"), libicu-dev would effectively become M-A:no as its dependencies cannot be satisfied for multiple architectures simultaneously. At that point we can merge the new package into libicu-dev dropping M-A:same. So the actual implementation of this sketch would be: * Move icu-config from icu-devtools to libicu-dev. * Turn libicu-dev M-A:no. * Add relevant Replaces. > > Can you elaborate what is broken by dropping M-A:same? Most of the time, > well one needs icu-devtools for build architecture, and icu-dev for > host architecture. However, the full combination of tools used during > compilation inside Ubuntu touch SDK need to compile native tools which > happen to link against icu-dev, thus the enablement of making icu-dev > to be M-A:same. In this case, I suggest to keep Ubuntu independent of Debian. The removal of M-A:same is meant to be temporary. Ubuntu doesn't have to follow. I think that removing M-A:same from libicu-dev is a fair compromise between ensuring that nothing breaks natively and enabling some cross-compilation. I prepared a patch, but it is yet untested due to -ENOSPC here. > Maybe we can be pragmatic and fix icu-config script to call into > pkg-config and make it multiarch aware without changing any binary > packages (that is not move things between binary packages, nor > introduce new packages nor change the M-A headers on existing > packages)? As much as I'd like this to be possible: It isn't. In order for pkg-config to work with cross-building properly it must be called via the cross-wrapper i.e. as $(DEB_HOST_GNU_TYPE)-pkg-config. When icu-config is invoked, we already no longer know which architecture is destined to be the host architecture, so we do not know how we would have to call pkg-config. Helmut diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog --- icu-52.1/debian/changelog 2015-01-22 03:47:39.0 +0100 +++ icu-52.1/debian/changelog 2015-02-06 19:39:01.0 +0100 @@ -1,3 +1,13 @@ +icu (52.1-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move icu-config to a M-A:no package. (Closes: #776821) ++ Move icu-config from icu-devtools to libicu-dev. ++ Declare relevant Breaks and Replaces. ++ Remove Multi-Arch:same from libicu-dev. + + -- Helmut Grohne Fri, 06 Feb 2015 19:29:44 +0100 + icu (52.1-7) unstable; urgency=high * Patch to CVE-2014-6591, CVE-2014-6585 a font parsing bug. diff -Nru icu-52.1/debian/control icu-52.1/debian/control --- icu-52.1/debian/control 2015-01-22 03:47:39.0 +0100 +++ icu-52.1/debian/control 2015-02-06 19:32:19.0 +0100 @@ -32,9 +32,10 @@ Package: libicu-dev Section: libdevel Architecture: any -Multi-Arch: same Pre-Depends: ${misc:Pre-Depends} Depends: ${misc:Depends}, ${shlibs:Depends}, libicu52 (= ${binary:Version}), icu-devtools (>= ${binary:Version}), libc6-dev | libc-dev +Replaces: icu-devtools (<< 52.1-7.1~) +Breaks: icu-devtools (<< 52.1-7.1~) Suggests: icu-doc Description: Development files for International Components for Unicode ICU is a C++ and C library that provides robust and full-featured diff -Nru icu-52.1/debian/icu-devtools.install icu-52.1/debian/icu-devtools.install --- icu-52.1/debian/icu-devtools.install2015-01-22 03:47:39.0 +0100 +++ icu-52.1/debian/icu-devtools.install2015-02-06 19:30:38.0 +0100 @@ -1,3 +1,12 @@ -usr/bin +usr/bin/derb +usr/bin/genbrk +usr/bin/gencfu +usr/bin/gencnval +usr/bin/gendict +usr/bin/genrb +usr/bin/icuinfo +usr/bin/makeconv +usr/bin/pkgdata +usr/bin/uconv usr/sbin usr/share/man diff -Nru icu-52.1/debian/libicu-dev.install icu-52.1/debian/libicu-dev.install --- icu-52.1/debian/libicu-dev.install 2015-01-22 03:47:39.0 +0100 +++ icu-52.1/debian/libicu-dev.install 2015-02-06 19:30:52.0 +0100 @@ -1,3 +1,4 @@ +usr/bin/icu-config usr/lib/*/lib*.so usr/lib/*/lib*.a usr/lib/*/icu
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On 2 February 2015 at 19:08, Helmut Grohne wrote: > On Mon, Feb 02, 2015 at 05:32:19PM +, Dimitri John Ledkov wrote: >> huh? I don't see a trivial one-line fix here, dropping M-A:foreign >> from devtools will revoke cross-compilation of packages of all -dev >> packages that depend on icu-dev, as well as a tonne of things that are >> cross-compiled using multiarch on daily basis. > > Funny, cross building libxml2 only works after dropping M-A:foreign, so > your claim clearly is wrong. The reverse holds: Dropping M-A:foreign > makes some reverse depends of libicu-dev cross-buildable! > > Also note that icu itself is not cross-buildable. I shall send a patch > for this issue. > > Jokes aside, I do recognize that dropping M-A:foreign poses a regression > and that we want to avoid this. I proposed it, because it disables > functionality instead feeding wrong configuration to builds. > > The real solution of course involves keeping M-A:foreign on the > devtools. > >> icu-config binary is not in the M-A:same package. That fact is not >> hidden, but rather well known that one must use pkgconfig to >> cross-compile things against icu. > > In that case, icu-devtools should simply not be containing icu-config. > Furthermore, all packages using icu-config should be RC-buggy. If you > agree, I shall clone bugs for the following packages > (over-approximation): > > prelude-lml openttd 389-adminutil libfolia texlive-bin qt4-x11 libe-book > xdvik-ja harfbuzz 389-dsgw gnustep-base iceweasel ncbi-blast+ dwdiff > open-vm-tools chromium-browser autoconf-archive gnustep-gui libreoffice > grcompiler qtwebkit libvisio yaz openjfx libcdr dee ibus-qt fis-gtm > 389-admin 389-ds-base php5 webkitgtk libxml2 wine-gecko-2.24 an couchdb > raptor2 0ad ucto phantomjs xerces-c python-apsw mozjs24 node-stringprep > sword texlive-base icedove libmspub parrot qtwebkit-opensource-src frog > I thing ultimately we do want to drop icu-config. That would have to be a mass-bugfile "icu-config is to be dropped, which will make your package FTBFS", followed on by patches / MUs / NMUs, followed by dropping icu-config -> RC bugs, migration complete. An interim solution could be to split icu-config binary into it's own M-A:nothing package, but imho that's too late for jessie, and makes not much sense for jessie+1 given that we would drop that. And see more below. >> That buildlog is incomplete.. i can spin up buildd-from-hell and >> fail a huge number of packages in Debian. See past efforts from Lucas. >> >> Could you please provide complete builldlog? Or steps that I can use >> to reproduce that build you provide? > > It's a clean pbuilder chroot with i386 as a foreign architecture that > selected icu-devtools:i386 instead of icu-devtools:amd64. If M-A:foreign > were correct on icu-devtools, this wouldn't make a difference to the > build. > >> The correct patch is to e.g. make libxml2 to use pkg-config. > > I agree. > >> One cannot have it all ways: >> - dropping M-A:same on the icu-dev package breaks existing users that >> cross-compile things against icu (e.g. Qt5 based apps) > > Can you elaborate what is broken by dropping M-A:same? Most of the time, Ubuntu touch SDK which is used for cross-compilation of Qt5 native and QML apps. In essence, it's not due to icu-config, as that is unused, but due to all the other tools in the devtools package that should be M-A:foreign. > you only need the development packages for the host architecture. At > which point do you need it for multiple architectures? I know that this > happens occasionally, so I'd like to learn where precisely. > well one needs icu-devtools for build architecture, and icu-dev for host architecture. However, the full combination of tools used during compilation inside Ubuntu touch SDK need to compile native tools which happen to link against icu-dev, thus the enablement of making icu-dev to be M-A:same. >> - having things rely on icu-config prevents things to be cross-compilable >> - dropping icu-config script will break a lot of native compilation >> which is far worse at this point in the cycle. > > I agree that we cannot have all of the above. Still having icu-config in > anything else but a M-A:no package is wrong and breaks things. If > removing M-A:foreign is not an option, we should seek different > solutions instead of denying the problem. > >> Please also see the huge amount of discussions we had on this issue in >> the prior bug reports when icu-devtools package was introduced. > > Are you referring to #699763? Maybe I am missing something here. > > I see that all ways to move from here cause pain. From my perspective, > the ideal outcome would be to remove icu-config, but clearly this is out > of scope for jessie. > > The next solution I see may be out of scope for jessie as well: > * Rename libicu-dev to libicu-dev-multiarch. > * Introduce a new binary Arch:any M-A:no package libicu-dev that >depends on libicu-dev-multiarch and takes icu-config over from
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
Control: tags -1 + patch On Mon, Feb 02, 2015 at 08:08:31PM +0100, Helmut Grohne wrote: > Funny, cross building libxml2 only works after dropping M-A:foreign, so > your claim clearly is wrong. The reverse holds: Dropping M-A:foreign > makes some reverse depends of libicu-dev cross-buildable! Given that: * icu-devtools currently can cause broken native builds (which is a regression from wheezy). * icu was not multiarch-aware in wheezy, so making it non-multiarch is not a regression. * Some packages (e.g. libxml2) become cross-buildable by removing M-A:foreign. I believe that removing M-A:foreign is the right fix with minimal changes for jessie. To that end I created a patch. Any objections to NMUing that? Helmut diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog --- icu-52.1/debian/changelog 2015-01-22 03:47:39.0 +0100 +++ icu-52.1/debian/changelog 2015-02-05 22:10:26.0 +0100 @@ -1,3 +1,11 @@ +icu (52.1-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Remove M-A:foreign from icu-devtools as icu-config is +architecture-specific. (Closes: #-1) + + -- Helmut Grohne Thu, 05 Feb 2015 22:10:05 +0100 + icu (52.1-7) unstable; urgency=high * Patch to CVE-2014-6591, CVE-2014-6585 a font parsing bug. diff -Nru icu-52.1/debian/control icu-52.1/debian/control --- icu-52.1/debian/control 2015-01-22 03:47:39.0 +0100 +++ icu-52.1/debian/control 2015-02-05 22:10:34.0 +0100 @@ -44,7 +44,6 @@ Package: icu-devtools Section: libdevel Architecture: any -Multi-Arch: foreign Pre-Depends: ${misc:Pre-Depends} Depends: ${misc:Depends}, ${shlibs:Depends} Replaces: libicu-dev (<< ${binary:Version}), icu-tools (<< 52.1-3~)
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Mon, Feb 02, 2015 at 05:32:19PM +, Dimitri John Ledkov wrote: > huh? I don't see a trivial one-line fix here, dropping M-A:foreign > from devtools will revoke cross-compilation of packages of all -dev > packages that depend on icu-dev, as well as a tonne of things that are > cross-compiled using multiarch on daily basis. Funny, cross building libxml2 only works after dropping M-A:foreign, so your claim clearly is wrong. The reverse holds: Dropping M-A:foreign makes some reverse depends of libicu-dev cross-buildable! Also note that icu itself is not cross-buildable. I shall send a patch for this issue. Jokes aside, I do recognize that dropping M-A:foreign poses a regression and that we want to avoid this. I proposed it, because it disables functionality instead feeding wrong configuration to builds. The real solution of course involves keeping M-A:foreign on the devtools. > icu-config binary is not in the M-A:same package. That fact is not > hidden, but rather well known that one must use pkgconfig to > cross-compile things against icu. In that case, icu-devtools should simply not be containing icu-config. Furthermore, all packages using icu-config should be RC-buggy. If you agree, I shall clone bugs for the following packages (over-approximation): prelude-lml openttd 389-adminutil libfolia texlive-bin qt4-x11 libe-book xdvik-ja harfbuzz 389-dsgw gnustep-base iceweasel ncbi-blast+ dwdiff open-vm-tools chromium-browser autoconf-archive gnustep-gui libreoffice grcompiler qtwebkit libvisio yaz openjfx libcdr dee ibus-qt fis-gtm 389-admin 389-ds-base php5 webkitgtk libxml2 wine-gecko-2.24 an couchdb raptor2 0ad ucto phantomjs xerces-c python-apsw mozjs24 node-stringprep sword texlive-base icedove libmspub parrot qtwebkit-opensource-src frog > That buildlog is incomplete.. i can spin up buildd-from-hell and > fail a huge number of packages in Debian. See past efforts from Lucas. > > Could you please provide complete builldlog? Or steps that I can use > to reproduce that build you provide? It's a clean pbuilder chroot with i386 as a foreign architecture that selected icu-devtools:i386 instead of icu-devtools:amd64. If M-A:foreign were correct on icu-devtools, this wouldn't make a difference to the build. > The correct patch is to e.g. make libxml2 to use pkg-config. I agree. > One cannot have it all ways: > - dropping M-A:same on the icu-dev package breaks existing users that > cross-compile things against icu (e.g. Qt5 based apps) Can you elaborate what is broken by dropping M-A:same? Most of the time, you only need the development packages for the host architecture. At which point do you need it for multiple architectures? I know that this happens occasionally, so I'd like to learn where precisely. > - having things rely on icu-config prevents things to be cross-compilable > - dropping icu-config script will break a lot of native compilation > which is far worse at this point in the cycle. I agree that we cannot have all of the above. Still having icu-config in anything else but a M-A:no package is wrong and breaks things. If removing M-A:foreign is not an option, we should seek different solutions instead of denying the problem. > Please also see the huge amount of discussions we had on this issue in > the prior bug reports when icu-devtools package was introduced. Are you referring to #699763? Maybe I am missing something here. I see that all ways to move from here cause pain. From my perspective, the ideal outcome would be to remove icu-config, but clearly this is out of scope for jessie. The next solution I see may be out of scope for jessie as well: * Rename libicu-dev to libicu-dev-multiarch. * Introduce a new binary Arch:any M-A:no package libicu-dev that depends on libicu-dev-multiarch and takes icu-config over from icu-devtools. This has the following advantages: * All reverse dependencies of libicu-dev will keep working natively and some will become cross-buildable (e.g. libxml2). * Packages that know about pkg-config and need libicu-dev for multiple architectures (presumably a minority) can switch over to depending on libicu-dev-multiarch. So what do we do for jessie if dropping M-A:foreign is not an option? Clearly, icu-devtools is broken natively at this point and needs some fix. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On 2 February 2015 at 17:19, Helmut Grohne wrote: > On Mon, Feb 02, 2015 at 12:36:14PM +, Dimitri John Ledkov wrote: >> I do not agree with severity of this bug report, as no other packages >> are FTBFS caused by this issue. > > Is it really necessary to discuss severity of a bug with a trivial > one-line fix? Either way, let the release team or maintainer downgrade. > huh? I don't see a trivial one-line fix here, dropping M-A:foreign from devtools will revoke cross-compilation of packages of all -dev packages that depend on icu-dev, as well as a tonne of things that are cross-compiled using multiarch on daily basis. >> It is known that icu-config (and similar legacy/pre-pkg-config >> *-config binaries) are not multiarch aware, and only ever output >> results for the architecture they were compiled. > > Exactly, and this is the reason why -dev packages with *-config scripts > must never become M-A:same (or hide this via a M-A:foreign -devtools > package). > icu-config binary is not in the M-A:same package. That fact is not hidden, but rather well known that one must use pkgconfig to cross-compile things against icu. >> Due to this, it is clearly a M-A:foreign package, and it is up to the >> user to pull in the right arch one which in most cases is the >> icu-devtools:native one. > > No, this is wrong. While the user bears the responsibility of actually > being able to execute code in the package (or not executing it), the > package maintainer bears the responsibility that the behaviour of the > contained tools does not vary per architecture. > > See for example libgpg-error. libgpg-error-dev is M-A:no, because it > contains gpg-error-config. A comprehensive discussion can be found in > bug #643341. If you find a -dev package with a *-config tool that is not > M-A:no, then this is a bug. Can you name one? > >> Are there any existing dependencies in the archive that cause to pull >> in a wrong arch icu-devtools and produce undesired effects? > > Please find a failing build log of libxml2 attached. Build-Depends were > satisfied. > That buildlog is incomplete.. i can spin up buildd-from-hell and fail a huge number of packages in Debian. See past efforts from Lucas. Could you please provide complete builldlog? Or steps that I can use to reproduce that build you provide? > Beyond this, having icu-config in a M-A:foreign package utterly breaks > cross-compilation of its reverse dependencies. There is no question > whether this needs fixing. It may be a question of whether it needs > fixing for jessie as cross toolchains didn't make it, but people do > build their own as we learned in the ctte bug. The correct patch is to e.g. make libxml2 to use pkg-config. One cannot have it all ways: - dropping M-A:same on the icu-dev package breaks existing users that cross-compile things against icu (e.g. Qt5 based apps) - having things rely on icu-config prevents things to be cross-compilable - dropping icu-config script will break a lot of native compilation which is far worse at this point in the cycle. Please also see the huge amount of discussions we had on this issue in the prior bug reports when icu-devtools package was introduced. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Mon, Feb 02, 2015 at 12:36:14PM +, Dimitri John Ledkov wrote: > I do not agree with severity of this bug report, as no other packages > are FTBFS caused by this issue. Is it really necessary to discuss severity of a bug with a trivial one-line fix? Either way, let the release team or maintainer downgrade. > It is known that icu-config (and similar legacy/pre-pkg-config > *-config binaries) are not multiarch aware, and only ever output > results for the architecture they were compiled. Exactly, and this is the reason why -dev packages with *-config scripts must never become M-A:same (or hide this via a M-A:foreign -devtools package). > Due to this, it is clearly a M-A:foreign package, and it is up to the > user to pull in the right arch one which in most cases is the > icu-devtools:native one. No, this is wrong. While the user bears the responsibility of actually being able to execute code in the package (or not executing it), the package maintainer bears the responsibility that the behaviour of the contained tools does not vary per architecture. See for example libgpg-error. libgpg-error-dev is M-A:no, because it contains gpg-error-config. A comprehensive discussion can be found in bug #643341. If you find a -dev package with a *-config tool that is not M-A:no, then this is a bug. Can you name one? > Are there any existing dependencies in the archive that cause to pull > in a wrong arch icu-devtools and produce undesired effects? Please find a failing build log of libxml2 attached. Build-Depends were satisfied. Beyond this, having icu-config in a M-A:foreign package utterly breaks cross-compilation of its reverse dependencies. There is no question whether this needs fixing. It may be a question of whether it needs fixing for jessie as cross toolchains didn't make it, but people do build their own as we learned in the ctte bug. Helmut dpkg-buildpackage: source package libxml2 dpkg-buildpackage: source version 2.9.2+dfsg1-3 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Aron Xu dpkg-source --before-build libxml2-2.9.2+dfsg1 dpkg-buildpackage: host architecture amd64 debian/rules clean dh clean --with autoreconf,python2 dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory '/tmp/buildd/libxml2-2.9.2+dfsg1' rm -rf builddir debian/tmp-dbg debian/tmp-udeb dh_auto_clean make[1]: Leaving directory '/tmp/buildd/libxml2-2.9.2+dfsg1' dh_autoreconf_clean dh_clean rm -f debian/libxml2.substvars rm -f debian/libxml2.*.debhelper rm -rf debian/libxml2/ rm -f debian/libxml2-utils.substvars rm -f debian/libxml2-utils.*.debhelper rm -rf debian/libxml2-utils/ rm -f debian/libxml2-utils-dbg.substvars rm -f debian/libxml2-utils-dbg.*.debhelper rm -rf debian/libxml2-utils-dbg/ rm -f debian/libxml2-dev.substvars rm -f debian/libxml2-dev.*.debhelper rm -rf debian/libxml2-dev/ rm -f debian/libxml2-dbg.substvars rm -f debian/libxml2-dbg.*.debhelper rm -rf debian/libxml2-dbg/ rm -f debian/libxml2-doc.substvars rm -f debian/libxml2-doc.*.debhelper rm -rf debian/libxml2-doc/ rm -f debian/python-libxml2.substvars rm -f debian/python-libxml2.*.debhelper rm -rf debian/python-libxml2/ rm -f debian/python-libxml2-dbg.substvars rm -f debian/python-libxml2-dbg.*.debhelper rm -rf debian/python-libxml2-dbg/ rm -f debian/*.debhelper.log rm -f debian/files find . \( \( \ \( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \ \( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \ -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \ -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \ -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \ \) -exec rm -f {} + \) -o \ \( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) \) rm -f *-stamp debian/rules build-arch dh_autoreconf find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.before autoreconf -f -i libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' configure.ac:52: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see: configure.ac:52: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005f
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
On Mon, 2 Feb 2015 08:43:14 +0100 Helmut Grohne wrote: > Package: icu-devtools > Version: 52.1-7 > Severity: serious > Justification: can cause other packages to FTBFS > User: helm...@debian.org > Usertags: rebootstrap > > The icu-devtools is marked as Multi-Arch:foreign. It contains the > icu-config program, which exposes architecture dependent paths. By > accidentally installing a wrong-arch icu-devtools, builds that use > libicu-dev (even natively) fail (execution of icu-config fails sanity > check). While this is unlikely to happen on buildds (as they generally > don't enable multiarch), it is possible on developer machines. > > An immediate remedy to solve this bug is to remove M-A:foreign from > icu-devtools and is what I would propose for jessie. > > As a mid term solution, I propose moving icu-config from icu-devtools to > libicu-dev. Then icu-devtools should be able to become M-A:foreign > again. Of course, libicu-dev must be M-A:no then and it certainly must > be M-A:no as long as icu-config is in use. > > The long term solution is to move to pkg-config and remove icu-config > entirely. I do not agree with severity of this bug report, as no other packages are FTBFS caused by this issue. It is known that icu-config (and similar legacy/pre-pkg-config *-config binaries) are not multiarch aware, and only ever output results for the architecture they were compiled. Due to this, it is clearly a M-A:foreign package, and it is up to the user to pull in the right arch one which in most cases is the icu-devtools:native one. Are there any existing dependencies in the archive that cause to pull in a wrong arch icu-devtools and produce undesired effects? Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776821: icu-devtools is wrongly marked Multi-Arch:foreign
Package: icu-devtools Version: 52.1-7 Severity: serious Justification: can cause other packages to FTBFS User: helm...@debian.org Usertags: rebootstrap The icu-devtools is marked as Multi-Arch:foreign. It contains the icu-config program, which exposes architecture dependent paths. By accidentally installing a wrong-arch icu-devtools, builds that use libicu-dev (even natively) fail (execution of icu-config fails sanity check). While this is unlikely to happen on buildds (as they generally don't enable multiarch), it is possible on developer machines. An immediate remedy to solve this bug is to remove M-A:foreign from icu-devtools and is what I would propose for jessie. As a mid term solution, I propose moving icu-config from icu-devtools to libicu-dev. Then icu-devtools should be able to become M-A:foreign again. Of course, libicu-dev must be M-A:no then and it certainly must be M-A:no as long as icu-config is in use. The long term solution is to move to pkg-config and remove icu-config entirely. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org