Processed: Re: Bug#452226: dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental
Processing commands for [EMAIL PROTECTED]: > reassign 452226 kdebase 4:3.96.0-1 Bug#452226: dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental Bug reassigned from package `dpkg-dev' to `kdebase'. > retitle 452226 FTFBS due to missing dependency information Bug#452226: dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental Changed Bug title to `FTFBS due to missing dependency information' from `dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452226: dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental
reassign 452226 kdebase 4:3.96.0-1 retitle 452226 FTFBS due to missing dependency information thanks Hi, On Wed, 21 Nov 2007, brian m. carlson wrote: > Package: dpkg-dev > Version: 1.14.9 > Severity: serious > File: /usr/bin/dpkg-shlibdeps > Justification: breaks unrelated packages (through build-essential) > > dpkg-shlibdeps has regressed. It now causes kdebase/experimental (3.96.0) > to FTBFS with the following error messages: It has not regressed, it's just no more accepting things that are *wrong* like a public library without shlibs information. It has been announced quite some time in advance: http://lists.debian.org/debian-devel-announce/2007/09/msg4.html You have 3 solutions: - make sure that the lib has no SONAME so that it's identified by dpkg-shlibdeps as a private library - add --ignore-missing-info to the dpkg-shlibdeps call (you can pass this via "dh_shlibdeps -- --ignore-missing-info") - add dependency information for this library (shlibs is not possible given that it has no version, however symbols files are possible) > I would provide you with more information if it were clear from the error > messages what name and version you were looking for. Ah, it seems that > dpkg-shlibdeps assumes a certain format for SONAMEs, even though this > shared object appears to be a private plugin specific to the konqueror > package. It has no characteristic of a private plugin (it has a SONAME, it's in a public directory). > Perhaps Dpkg::Shlibs::Objdump should instead determine that something is a > public library if it has a certain SONAME format (as well as DYNAMIC), and > instead punt if it doesn't. During the discussions on -devel, Steve Langasek suggested me to use the SONAME+DYNAMIC as the criterion to define a public library. > Then extract_from_shlibs would not need that > code, and although no shlibs file would be generated, it would at least not > cause the build to fail. > > dpkg 1.14.7 says instead: > dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_keditbookmarks.so' not > recognized > dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_kfmclient.so' not > recognized > dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_konqueror.so' not > recognized > > but it does not fail. It's not the lack of version that makes it fail. It's the lack of dependency information. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452226: dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental
Package: dpkg-dev Version: 1.14.9 Severity: serious File: /usr/bin/dpkg-shlibdeps Justification: breaks unrelated packages (through build-essential) dpkg-shlibdeps has regressed. It now causes kdebase/experimental (3.96.0) to FTBFS with the following error messages: dpkg-shlibdeps: warning: Can't extract name and version from library name `libkdeinit4_kfmclient.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `libkdeinit4_kfmclient.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `libkdeinit4_kfmclient.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `libkdeinit4_kfmclient.so' dpkg-shlibdeps: warning: Can't extract name and version from library name `libkdeinit4_kfmclient.so' dpkg-shlibdeps: failure: No dependency information found for libkdeinit4_kfmclient.so (used by debian/konqueror/usr/bin/kfmclient). dh_shlibdeps: command returned error code 512 make: *** [binary-predeb-IMPL/konqueror] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 Several thousand other warning messages are present, but since those do not cause an FTBFS, I have not pasted them here. objdump output is below: stonewall ok % objdump -x ./konqueror/usr/lib/libkdeinit4_kfmclient.so | grep -E '(SONAME|NEEDED)' NEEDED libQtCore.so.4 NEEDED libpthread.so.0 NEEDED libkdecore.so.5 NEEDED libkdeui.so.5 NEEDED libz.so.1 NEEDED libstreamanalyzer.so.0 NEEDED libstreams.so.0 NEEDED libsolid.so.4 NEEDED libfam.so.0 NEEDED libXrender.so.1 NEEDED libkio.so.5 NEEDED libQtSvg.so.4 NEEDED libSM.so.6 NEEDED libICE.so.6 NEEDED libX11.so.6 NEEDED libXext.so.6 NEEDED libXft.so.2 NEEDED libXau.so.6 NEEDED libXdmcp.so.6 NEEDED libXtst.so.6 NEEDED libXcursor.so.1 NEEDED libXfixes.so.3 NEEDED libQtNetwork.so.4 NEEDED libbz2.so.1.0 NEEDED libresolv.so.2 NEEDED libQtDBus.so.4 NEEDED libQtXml.so.4 NEEDED libQtGui.so.4 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libc.so.6 NEEDED libgcc_s.so.1 SONAME libkdeinit4_kfmclient.so I would provide you with more information if it were clear from the error messages what name and version you were looking for. Ah, it seems that dpkg-shlibdeps assumes a certain format for SONAMEs, even though this shared object appears to be a private plugin specific to the konqueror package. Dpkg::Shlibs::Objdump seems to be under the mistaken impression that having DYNAMIC and SONAME makes something a public library, and the combination of these two bugs causes the error listed above. Perhaps Dpkg::Shlibs::Objdump should instead determine that something is a public library if it has a certain SONAME format (as well as DYNAMIC), and instead punt if it doesn't. Then extract_from_shlibs would not need that code, and although no shlibs file would be generated, it would at least not cause the build to fail. dpkg 1.14.7 says instead: dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_keditbookmarks.so' not recognized dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_kfmclient.so' not recognized dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_konqueror.so' not recognized but it does not fail. N.B. Although the versions of dpkg-dev and dpkg are correct, this report was not generated on the failing system. Consequently, other package versions may not be correct. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils2.18.1~cvs20071027-1 The GNU assembler, linker and bina ii cpio2.9-6GNU cpio -- a program to manage ar ii dpkg1.14.9 package maintenance system for Deb ii make3.81-3 The GNU version of the "make" util ii patch 2.5.9-4 Apply a diff file to an original ii perl [perl5]5.8.8-12 Larry Wall's Practical Extraction ii perl-modules5.8.8-12 Core Perl modules Versions of packages dpkg-dev recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-17 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.2-3The GNU C compiler ii gcc-4.3 [c-compiler] 4.3-20070902-1 The GNU C compiler -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US +1 71
Bug#39893: Create a successful career within our company
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#202247: Create a successful career within our company
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#4655: Join our marketing team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#193883: Would you like to work with our team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#9771: Join our marketing team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#211886: Would you like to work with our team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#193934: Join our marketing team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. Wjavascript:checkSpamAssassin(); ðÒÏ×ÅÒËÁ SpamAssassin-ÏÍe are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Raphael Hertzog a écrit : > On Tue, 20 Nov 2007, Aurelien Jarno wrote: Please read the bug log again. The supplementary symbols are not the same on the different architectures, which causes some architectures to have missing symbols compared to some others. >>> In which case it doesn't make sense to have a common symbols file and the >>> problem is solved. >> Except that the problem appearing only on unofficial architectures, mole >> provide a common symbols file. That is where the problem lies. > > If we manage to have common symbol set for hurd-i386 and all the other > arches, then I think it should be doable to have the same symbol set on > unofficial architectures (or at least a superset). You can get data for kfreebsd-i386, kfreebsd-amd64 and armel from gnuab.org. The repository is rsyncable, and we can even send a push signal. But that don't solve the problem for other unofficial architectures (what comes to mind is nexenta, sh4, m32r). >>> So the initial problem is not armel-specific and I fail to see why >>> we should ignore it when this failure enabled us to discover a bug in >>> libtool. >> Even if the bug is present in all architectures, its effects are only >> visible on armel. And maintainers do not care about unofficial >> architectures, so the package will simply FTBFS. > > The fix is to remove one private symbol from the debian/*.symbols file so > that the lack of the symbol doesn't generate a failure. This fix is > trivial and can be done easily in a porter NMU without risking to break > everything. > >> libtool is buggy, and that is even more true for older versions. And if >> you look at the archive, you will see that most of libraries use an old >> libtool version. > > Indeed, but maybe the implementation of proper symbols versioning in the > debian package will trigger the required relibtoolizing... because > hurd-i386 also needs it in many cases. > >> The library has to fixed, but the job of porters is not to fix general >> problems with libraries, we already have a lot of work to do in other >> domains. But if porters doesn't fix this, the maintainer will simply >> ignore the problem, even if a bug report is sent. > > If we follow your logic, we shouldn't do anything because maintainers are > not doing their work. While there's some truth in that, I just can't > accept this conclusion. You are changing the truth. I never said "we shouldn't do anything", I proposed solutions so that the packages do not FTBFS on unofficial architectures. But you rejecting most them, instead trying to convince me there is no or very few problems. Also note that the main difference is that FTBFS are considered RC for official architectures, so if a maintainer don't do his/her job, others can NMU the package. That is not true for unofficial architecture, even if we managed to NMU some of them when the maintainer is clearly MIA. > That said, we might want to have the possibility to flag private symbols > in symbols file and have a mode where the disparition of private symbols > doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. >>> Yes, but that's not something I control. In fact, if that's what you want, >>> it's better to fail so that we can report problems to maintainers who will >>> then prod upstream to implement a version script or similar. >> I totally agree it's better to fail in such cases, but it is better to >> fails on all architectures, so that the problem is not just ignored. > > If only... there's no way for me to know if a symbol was intendend to be > private or not. So I can't do this. > > Cheers, -- .''`. 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]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Hi, On armel architecture, the symbol differences have usually been inlined softfloat symbols being exported. Which is additional symbols and would thus not break symbol checking (if I understood correctly). What is more worrying is the lack of unofficial arch information in mole. Thus maintainers are not aware of issues with their packages on unofficial archs until someeon files a bug. I can also see that this potentially much bigger problem for hurd/kfreebsd. > Though it's worth asking ourselves if it would make sense to have an > intermediary fallback between debian/*.symbols. and > debian/*.symbols that would be debian/*.symbols.. One option would be to use dpkg-architecture provided variables: DEB_HOST_ARCH=armel DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=arm DEB_HOST_GNU_CPU=arm DEB_HOST_GNU_SYSTEM=linux-gnueabi DEB_HOST_GNU_TYPE=arm-linux-gnueabi Thus one can use DEB_HOST_ARCH for symbol files specific for one arch, DEB_HOST_ARCH_OS for kfreebsd/hurd DEB_HOST_ARCH_CPU when same set of symbols affects arm and armel or all > Because of a bug in libtool. I fail to see why we should be more lax > just because libtool has bugs. I think the pessimism to libtool comes from bugs like #347650 not getting solved over time.. mind you that bug would help with the same goal symbols file is working on - making transitions easier. For the c++ and -version-script bug, #430971 I think this might be much easier to fix. > That is not a correct solution. If you are able to list private > symbols, better not export them instead of flagging them. > Yes, but that's not something I control. In fact, if that's what you > want, it's better to fail so that we can report problems to maintainers who > will then prod upstream to implement a version script or similar. for most libraries, creating a version script should be be the same amount of work as separating private/public symbols in .symbols file. Also automatically generating .symbols file from version script should not be very hard. The big benefit of using version-scripts is that it makes dynamic linking much more faster, when the symbol tables have only the needed symbols. -- "rm -rf" only sounds scary if you don't have backups signature.asc Description: Digital signature
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: > >> Please read the bug log again. The supplementary symbols are not the > >> same on the different architectures, which causes some architectures to > >> have missing symbols compared to some others. > > > > In which case it doesn't make sense to have a common symbols file and the > > problem is solved. > > Except that the problem appearing only on unofficial architectures, mole > provide a common symbols file. That is where the problem lies. If we manage to have common symbol set for hurd-i386 and all the other arches, then I think it should be doable to have the same symbol set on unofficial architectures (or at least a superset). > > So the initial problem is not armel-specific and I fail to see why > > we should ignore it when this failure enabled us to discover a bug in > > libtool. > > Even if the bug is present in all architectures, its effects are only > visible on armel. And maintainers do not care about unofficial > architectures, so the package will simply FTBFS. The fix is to remove one private symbol from the debian/*.symbols file so that the lack of the symbol doesn't generate a failure. This fix is trivial and can be done easily in a porter NMU without risking to break everything. > libtool is buggy, and that is even more true for older versions. And if > you look at the archive, you will see that most of libraries use an old > libtool version. Indeed, but maybe the implementation of proper symbols versioning in the debian package will trigger the required relibtoolizing... because hurd-i386 also needs it in many cases. > The library has to fixed, but the job of porters is not to fix general > problems with libraries, we already have a lot of work to do in other > domains. But if porters doesn't fix this, the maintainer will simply > ignore the problem, even if a bug report is sent. If we follow your logic, we shouldn't do anything because maintainers are not doing their work. While there's some truth in that, I just can't accept this conclusion. > >>> That said, we might want to have the possibility to flag private symbols > >>> in symbols file and have a mode where the disparition of private symbols > >>> doesn't cause a failure. Not sure about it. > >> That is not a correct solution. If you are able to list private symbols, > >> better not export them instead of flagging them. > > > > Yes, but that's not something I control. In fact, if that's what you want, > > it's better to fail so that we can report problems to maintainers who will > > then prod upstream to implement a version script or similar. > > I totally agree it's better to fail in such cases, but it is better to > fails on all architectures, so that the problem is not just ignored. If only... there's no way for me to know if a symbol was intendend to be private or not. So I can't do this. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Raphael Hertzog a écrit : > On Tue, 20 Nov 2007, Aurelien Jarno wrote: >>> The issue is that some supplementary symbols are exported due to libtool >>> working differently with C++ libs for apparently no good reasons. It is not >>> really armel-specific (except for the fact that armel generated >>> supplementary symbols that should be not exported according to the version >>> script). >> Please read the bug log again. The supplementary symbols are not the >> same on the different architectures, which causes some architectures to >> have missing symbols compared to some others. > > In which case it doesn't make sense to have a common symbols file and the > problem is solved. Except that the problem appearing only on unofficial architectures, mole provide a common symbols file. That is where the problem lies. >>> In any case, having new symbols as is the case in those reports will not >>> generate a failure with the default behaviour of dpkg-gensymbols unless >>> the maintainer want those failures. >> Wrong. Some symbols are "missing" on armel: >> Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base >> QGList::count() const > > In turn this is caused by a bug in libtool because that symbol should > never have been exported on any arch... and on armel gcc was doing the > right thing by "inlining" the function properly. > > So the initial problem is not armel-specific and I fail to see why > we should ignore it when this failure enabled us to discover a bug in > libtool. Even if the bug is present in all architectures, its effects are only visible on armel. And maintainers do not care about unofficial architectures, so the package will simply FTBFS. > And if you want a permanent work-around, I already suggested the > environment variable. I haven't seen any other better alternative yet. > >>> So it's still not representative of failures that we're likely to get due >>> to dpkg-gensymbols (unless many maintainers decide to increase the level >>> of checks, which I doubt. Furthermore maintainers that do that are likely >>> reactive maintainer that will quickly integrate changes needed for >>> unofficial architectures). >> As explained, it would have also failed on armel without increasing the >> level of checks. > > Because of a bug in libtool. I fail to see why we should be more lax just > because libtool has bugs. libtool is buggy, and that is even more true for older versions. And if you look at the archive, you will see that most of libraries use an old libtool version. The library has to fixed, but the job of porters is not to fix general problems with libraries, we already have a lot of work to do in other domains. But if porters doesn't fix this, the maintainer will simply ignore the problem, even if a bug report is sent. Just have a look to the following URL and see how many libtool bugs are ignored for a very long time: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;[EMAIL PROTECTED];pri0=pending:pending,forwarded,pending-fixed,fixed;ttl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU;pri1=pending%3dpending%2btag%3dwontfix,pending%3dpending%2btag%3dmoreinfo,pending%3dpending%2btag%3dpatch,pending%3dpending%2btag%3dconfirmed,pending%3dpending;ttl1=Will%20Not%20Fix,More%20information%20needed,Patch%20Available,Confirmed,Unclassified;ord1=2,3,4,1,0,5 >>> That said, we might want to have the possibility to flag private symbols >>> in symbols file and have a mode where the disparition of private symbols >>> doesn't cause a failure. Not sure about it. >> That is not a correct solution. If you are able to list private symbols, >> better not export them instead of flagging them. > > Yes, but that's not something I control. In fact, if that's what you want, > it's better to fail so that we can report problems to maintainers who will > then prod upstream to implement a version script or similar. I totally agree it's better to fail in such cases, but it is better to fails on all architectures, so that the problem is not just ignored. -- .''`. 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]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: > > The issue is that some supplementary symbols are exported due to libtool > > working differently with C++ libs for apparently no good reasons. It is not > > really armel-specific (except for the fact that armel generated > > supplementary symbols that should be not exported according to the version > > script). > > Please read the bug log again. The supplementary symbols are not the > same on the different architectures, which causes some architectures to > have missing symbols compared to some others. In which case it doesn't make sense to have a common symbols file and the problem is solved. > > In any case, having new symbols as is the case in those reports will not > > generate a failure with the default behaviour of dpkg-gensymbols unless > > the maintainer want those failures. > > Wrong. Some symbols are "missing" on armel: > Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base > QGList::count() const In turn this is caused by a bug in libtool because that symbol should never have been exported on any arch... and on armel gcc was doing the right thing by "inlining" the function properly. So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. And if you want a permanent work-around, I already suggested the environment variable. I haven't seen any other better alternative yet. > > So it's still not representative of failures that we're likely to get due > > to dpkg-gensymbols (unless many maintainers decide to increase the level > > of checks, which I doubt. Furthermore maintainers that do that are likely > > reactive maintainer that will quickly integrate changes needed for > > unofficial architectures). > > As explained, it would have also failed on armel without increasing the > level of checks. Because of a bug in libtool. I fail to see why we should be more lax just because libtool has bugs. > > That said, we might want to have the possibility to flag private symbols > > in symbols file and have a mode where the disparition of private symbols > > doesn't cause a failure. Not sure about it. > > That is not a correct solution. If you are able to list private symbols, > better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#198339: rierojen
Long and big dragon as a symbol of your power Mikael Puljic http://heartoward.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Raphael Hertzog a écrit : > On Tue, 20 Nov 2007, Aurelien Jarno wrote: >>> Though it's worth asking ourselves if it would make sense to have an >>> intermediary fallback between debian/*.symbols. and debian/*.symbols >>> that >>> would be debian/*.symbols.. >> While it will fixes the problem due to the variation of the ABI across >> kernels, I am not sure that is the problem we will see the most. The >> most problematic variations, will happens on the same kernel, as it >> could be seen from bugs #441736, #429600 or #342084. > > Riku said in #441736: > "This is the same bug as on unixodbc, #429600, #342084." > > The issue is that some supplementary symbols are exported due to libtool > working differently with C++ libs for apparently no good reasons. It is not > really armel-specific (except for the fact that armel generated > supplementary symbols that should be not exported according to the version > script). Please read the bug log again. The supplementary symbols are not the same on the different architectures, which causes some architectures to have missing symbols compared to some others. > In any case, having new symbols as is the case in those reports will not > generate a failure with the default behaviour of dpkg-gensymbols unless > the maintainer want those failures. Wrong. Some symbols are "missing" on armel: Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base QGList::count() const > So it's still not representative of failures that we're likely to get due > to dpkg-gensymbols (unless many maintainers decide to increase the level > of checks, which I doubt. Furthermore maintainers that do that are likely > reactive maintainer that will quickly integrate changes needed for > unofficial architectures). As explained, it would have also failed on armel without increasing the level of checks. > That said, we might want to have the possibility to flag private symbols > in symbols file and have a mode where the disparition of private symbols > doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. -- .''`. 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]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: > > Though it's worth asking ourselves if it would make sense to have an > > intermediary fallback between debian/*.symbols. and debian/*.symbols > > that > > would be debian/*.symbols.. > > While it will fixes the problem due to the variation of the ABI across > kernels, I am not sure that is the problem we will see the most. The > most problematic variations, will happens on the same kernel, as it > could be seen from bugs #441736, #429600 or #342084. Riku said in #441736: "This is the same bug as on unixodbc, #429600, #342084." The issue is that some supplementary symbols are exported due to libtool working differently with C++ libs for apparently no good reasons. It is not really armel-specific (except for the fact that armel generated supplementary symbols that should be not exported according to the version script). In any case, having new symbols as is the case in those reports will not generate a failure with the default behaviour of dpkg-gensymbols unless the maintainer want those failures. So it's still not representative of failures that we're likely to get due to dpkg-gensymbols (unless many maintainers decide to increase the level of checks, which I doubt. Furthermore maintainers that do that are likely reactive maintainer that will quickly integrate changes needed for unofficial architectures). That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Raphael Hertzog a écrit : > On Tue, 20 Nov 2007, Raphael Hertzog wrote: >> Note that this is a case where the API is supposed to be stable across >> architectures... can you show me what the differences are and why they are >> legitimate? >> >> Please show me the build-failure. > > FTR, here's the relevant output for kfreebsd: > dh_makeshlibs -V -plibusb-0.1-4 --add-udeb="libusb-0.1-udeb" > dpkg-gensymbols: warning: some symbols disappeared in the symbols file. > dpkg-gensymbols: warning: debian/libusb-0.1-4/DEBIAN/symbols doesn't match > completely debian/libusb-0.1-4/DEBIAN/symbols > > --- dpkg-gensymbolsCjbx1b 2007-11-20 08:40:47 +0100 > +++ dpkg-gensymbolsa5oh1T 2007-11-20 08:40:47 +0100 > @@ -8,7 +8,7 @@ > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > - [EMAIL PROTECTED] 0.1.12-7 > +#DEPRECATED: 2:0.1.12-7# [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > @@ -21,7 +21,7 @@ > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > - [EMAIL PROTECTED] 0.1.12-7 > +#DEPRECATED: 2:0.1.12-7# [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > [EMAIL PROTECTED] 0.1.12-7 > dh_makeshlibs: command returned error code 256 > make: *** [binary-arch] Erreur 1 > > > This proves that with we will have legitimate API difference between > architectures who have differing kernels. I don't think it's representative of > the majority of packages though. > > Though it's worth asking ourselves if it would make sense to have an > intermediary fallback between debian/*.symbols. and debian/*.symbols > that > would be debian/*.symbols.. While it will fixes the problem due to the variation of the ABI across kernels, I am not sure that is the problem we will see the most. The most problematic variations, will happens on the same kernel, as it could be seen from bugs #441736, #429600 or #342084. -- .''`. 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]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
Raphael Hertzog a écrit : > On Tue, 20 Nov 2007, Aurelien Jarno wrote: >> Even if it is not important for you that doesn't give you the right to >> ignore the problem as you did until now. > > We've had only one unconclusive IRC discussion, that's not really ignoring > the problem. And I still believe, you're over exagerating the problem > unless there are good reasons why exported API differ on unofficial > architectures more than on official architectures (this could be the case > for kfreebsd-*, I don't know). > >> I guess it is also very important for the release team, because armel is >> supposed to be shipped with lenny in order to drop arm for lenny + 1. >> This architecture has to be kept in good shape. > > And we'll make sure to find a statisfying solution once you give me all > the relevant infos to really understand how far reaching the problem is. > >>> debian/.symbols. files then it will not fail because it >>> won't find a symbols file for the given architecture and will thus >>> generate a brand new one (and the comparison will only find new symbols >>> and it will not fail). >> As already explained, this is the case. Mole doesn't provide symbols for >> unofficial architectures (which I can understand), so packages will >> never have the symbols file for unofficial architectures. > > Did you read what I wrote? I said "it will not fail" if the package > provides only debian/*.symbols.. The ABI can be different on non official architectures, even if mole only provide a common file for all official architectures. >> And note that I am speaking of real examples. Just try on libusb for >> example. > > On which architecture did you try? And how? Where do I have an account on > an armel machine or a kfreebsd one? I did test on kfreebsd-i386, but history has prove that it can happens on other architecture: bugs #441736, #429600 or #342084. If you want to get access to a GNU/kFreeBSD machine, have a look to http://io.debian.net/ssh.html . > Note that this is a case where the API is supposed to be stable across > architectures... can you show me what the differences are and why they are > legitimate? > > Please show me the build-failure. Please see http://temp.aurel32.net/libusb_0.1.12-7_kfreebsd-i386.build >>> I won't harcode such a behaviour in dpkg. However what is doable is have >>> an environment variable that will override the "check level" that that the >>> package is using. Then you just have to make sure that the buildd of the >>> unofficial arches define that environment variable. >>> >>> Does that seem reasonable? >> Unfortunately I don't really like this idea because sbuild doesn't keep >> environment variables, and I don't really want to patch sbuild every >> time I want to update it instead of using the .deb package directly from >> debian-admin. > > This is surely a feature that could be added to sbuild. I asked neuro on > IRC, I'm waiting his answer. > > Cheers, -- .''`. 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]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Raphael Hertzog wrote: > Note that this is a case where the API is supposed to be stable across > architectures... can you show me what the differences are and why they are > legitimate? > > Please show me the build-failure. FTR, here's the relevant output for kfreebsd: dh_makeshlibs -V -plibusb-0.1-4 --add-udeb="libusb-0.1-udeb" dpkg-gensymbols: warning: some symbols disappeared in the symbols file. dpkg-gensymbols: warning: debian/libusb-0.1-4/DEBIAN/symbols doesn't match completely debian/libusb-0.1-4/DEBIAN/symbols --- dpkg-gensymbolsCjbx1b 2007-11-20 08:40:47 +0100 +++ dpkg-gensymbolsa5oh1T 2007-11-20 08:40:47 +0100 @@ -8,7 +8,7 @@ [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 - [EMAIL PROTECTED] 0.1.12-7 +#DEPRECATED: 2:0.1.12-7# [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 @@ -21,7 +21,7 @@ [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 - [EMAIL PROTECTED] 0.1.12-7 +#DEPRECATED: 2:0.1.12-7# [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 dh_makeshlibs: command returned error code 256 make: *** [binary-arch] Erreur 1 This proves that with we will have legitimate API difference between architectures who have differing kernels. I don't think it's representative of the majority of packages though. Though it's worth asking ourselves if it would make sense to have an intermediary fallback between debian/*.symbols. and debian/*.symbols that would be debian/*.symbols.. Opinions? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: > Even if it is not important for you that doesn't give you the right to > ignore the problem as you did until now. We've had only one unconclusive IRC discussion, that's not really ignoring the problem. And I still believe, you're over exagerating the problem unless there are good reasons why exported API differ on unofficial architectures more than on official architectures (this could be the case for kfreebsd-*, I don't know). > I guess it is also very important for the release team, because armel is > supposed to be shipped with lenny in order to drop arm for lenny + 1. > This architecture has to be kept in good shape. And we'll make sure to find a statisfying solution once you give me all the relevant infos to really understand how far reaching the problem is. > > debian/.symbols. files then it will not fail because it > > won't find a symbols file for the given architecture and will thus > > generate a brand new one (and the comparison will only find new symbols > > and it will not fail). > > As already explained, this is the case. Mole doesn't provide symbols for > unofficial architectures (which I can understand), so packages will > never have the symbols file for unofficial architectures. Did you read what I wrote? I said "it will not fail" if the package provides only debian/*.symbols.. > And note that I am speaking of real examples. Just try on libusb for > example. On which architecture did you try? And how? Where do I have an account on an armel machine or a kfreebsd one? Note that this is a case where the API is supposed to be stable across architectures... can you show me what the differences are and why they are legitimate? Please show me the build-failure. > > I won't harcode such a behaviour in dpkg. However what is doable is have > > an environment variable that will override the "check level" that that the > > package is using. Then you just have to make sure that the buildd of the > > unofficial arches define that environment variable. > > > > Does that seem reasonable? > > Unfortunately I don't really like this idea because sbuild doesn't keep > environment variables, and I don't really want to patch sbuild every > time I want to update it instead of using the .deb package directly from > debian-admin. This is surely a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
