Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote: Can someone fluent in C/C++ please look at this? Perhaps you, Adrian, since you seem most knowledgeable in JACK around here? Adrian, is there a jackd ABI definition? What symbols are supposed to be exposed by libjack? I suppose only globals and functions defined in these files are part of this: /usr/include/jack /usr/include/jack/intclient.h /usr/include/jack/jack.h /usr/include/jack/ringbuffer.h /usr/include/jack/statistics.h /usr/include/jack/thread.h /usr/include/jack/timestamps.h /usr/include/jack/transport.h /usr/include/jack/types.h /usr/include/jack/midiport.h But is there perhaps a more canonical list? Moreover, I see some functions marked as JACK_DEPRECATED in jack.h. Are they still used by applications and does jack2 still provide them? Ping! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote:
Can someone fluent in C/C++ please look at this? Perhaps you, Adrian,
since you seem most knowledgeable in JACK around here?
I think I qualify.
I'm not sure if I do. ;) Never used the debian symbol files...
Another source of problem is that presence of machine optimization. In
your buildlog I see symbols that indicate sse2 enabled functions. Has
anyone made sure that jackd2 really works on non-sse2 enabled machines?
I haven't checked, yet, but I have a Debian 486 machine around, so I
could try it. ;) Or I disassemble the library and check for SSE
instructions.
As long as nobody is calling -msse2 with the appropriate arch/cpu
definition, no SSE2 enabled code would be compiled.
(JFTR: SSE2 is available on all amd64 platforms)
Adrian, is there a jackd ABI definition?
No.
What symbols are supposed to be exposed by libjack? I suppose only
globals and functions defined in these files are part of this:
/usr/include/jack
/usr/include/jack/intclient.h
/usr/include/jack/jack.h
/usr/include/jack/ringbuffer.h
/usr/include/jack/statistics.h
/usr/include/jack/thread.h
/usr/include/jack/timestamps.h
/usr/include/jack/transport.h
/usr/include/jack/types.h
/usr/include/jack/midiport.h
Exactly. That's the list each client application relies on.
But is there perhaps a more canonical list?
There is doxygen output available:
http://jackaudio.org/files/docs/html/index.html
Don't know if this qualifies as more canonical, but this file also
refers to the above header files as the full API
Moreover, I see some functions marked as JACK_DEPRECATED in jack.h.
Are they still used by applications and does jack2 still provide them?
The deprecated functions are still provided and even used by
jackd{1,2}'s example clients. ;)
This surely needs fixing, but that's upstream's responsibility. I'll
file a ticket and provide some patches.
Is there more I could do?
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 02:34:37PM +0200, Reinhard Tartler wrote: On Thu, Apr 08, 2010 at 13:06:18 (CEST), Adrian Knoth wrote: On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote: Can someone fluent in C/C++ please look at this? Perhaps you, Adrian, since you seem most knowledgeable in JACK around here? I think I qualify. I'm not sure if I do. ;) Never used the debian symbol files... I did not expect you to understand the symbol file mechanism, but the underlying library symbols that are extracted by that mechanism. What I believe to have understood but is beyond me to work further on (and that I am hoping you guys could help with) is that C++ code (and C too?) should be able to mark a symbol as private - which the Debian symbol mechanism would then respect. Even if upstream do not maintain such hints, I would be willing to work on applying them as a patch to the Debian packaging, based on canonical documentation (i.e. Doxygen-generated documentation, apparently). But I need someone to help educate me on the syntax of such hints, and whether or not aplying those could affect the resulting code badly (except off course hinting wrongly, so parts of the public API gets hidden). I cannot code C or C++, but I can skim code, merge known patterns, and juggle patch files. :-) Another source of problem is that presence of machine optimization. Commenting on that separately, with changed subject line... What symbols are supposed to be exposed by libjack? I suppose only globals and functions defined in these files are part of this: /usr/include/jack /usr/include/jack/intclient.h /usr/include/jack/jack.h /usr/include/jack/ringbuffer.h /usr/include/jack/statistics.h /usr/include/jack/thread.h /usr/include/jack/timestamps.h /usr/include/jack/transport.h /usr/include/jack/types.h /usr/include/jack/midiport.h Exactly. That's the list each client application relies on. But is there perhaps a more canonical list? There is doxygen output available: http://jackaudio.org/files/docs/html/index.html Don't know if this qualifies as more canonical, but this file also refers to the above header files as the full API Well, I think this counts as canonical list. ok. Is there more I could do? I think as long upstream not even makes efford to hide symbols not defined in the JACK API as published at http://jackaudio.org/files/docs/html/index.html, I don't think it makes sense to think about symbol files. Ideally, every line in the symbol file corresponds directly to an API function or global, but this is much work that I don't think can be sensibly finished before squeeze release. Next steps (just opinion): - revert the symbol files change - upload to experimental ASAP - test-rebuild applications against jack2 - in paralell: review the license issues - upload to unstable if all OK I will not revert the symbol file change, but weaken them to only cause warnings (not build failure), when changing. And yes, if you coding experts (compared to me) consider the symbol differences between 1.1.x and 1.9.x not worrying, then I will proceed with releasing the current packaging, and postpone polishing the symbol file handling till later :-) If I run into no more problems then I see no problem in releasing directly to unstable. I.e. no need to first do experimental build. More opinions quite welcome! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 18:11:39 (CEST), Jonas Smedegaard wrote: On Thu, Apr 08, 2010 at 02:34:37PM +0200, Reinhard Tartler wrote: On Thu, Apr 08, 2010 at 13:06:18 (CEST), Adrian Knoth wrote: On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote: Can someone fluent in C/C++ please look at this? Perhaps you, Adrian, since you seem most knowledgeable in JACK around here? I think I qualify. I'm not sure if I do. ;) Never used the debian symbol files... I did not expect you to understand the symbol file mechanism, but the underlying library symbols that are extracted by that mechanism. What I believe to have understood but is beyond me to work further on (and that I am hoping you guys could help with) is that C++ code (and C too?) should be able to mark a symbol as private - which the Debian symbol mechanism would then respect. I've been investigating symbol files for FFmpeg, which doesn't really do symbol hiding as well. My conclusion was to not use symbol files of several reasons (the most important one doesn't apply to jack, but anyway) For C++ libraries, I don't see any point in using symbol files until dpkg-gensyms understands unmangled symbols. Working on demangled symbol is just too painful IMO. For jack, I think the amount of symbol files is just too much ATM. First, I'd strongly suggest to hide the symbols. Even if upstream do not maintain such hints, I would be willing to work on applying them as a patch to the Debian packaging, based on canonical documentation (i.e. Doxygen-generated documentation, apparently). But I need someone to help educate me on the syntax of such hints, and whether or not aplying those could affect the resulting code badly (except off course hinting wrongly, so parts of the public API gets hidden). I've done so for FFmpeg 0.6 by introducing a versioning script. While symbol versioning is currently not necessary, I think we can use the mechanism for jack as non-invasive technique as well. AFAIR, it is possible to mark symbols without version tags, so we should be able to retain full binary compatibility with other distros. If versioning script is not going to work for some reason, the other option is to extend the compilations flags to not export ANY symbols by default, and extend the public .h files to only export those functions and globals that are mentioned in the doxygen documentation. As this work is really tedious and hard to get right, I'd strongly suggest to do this work upstream; which means two upstreams in this case. :/ I cannot code C or C++, but I can skim code, merge known patterns, and juggle patch files. :-) Strong C/C++ skills are IMO absolutely necessary for properly maintaining symbol files. Is there more I could do? I think as long upstream not even makes efford to hide symbols not defined in the JACK API as published at http://jackaudio.org/files/docs/html/index.html, I don't think it makes sense to think about symbol files. Ideally, every line in the symbol file corresponds directly to an API function or global, but this is much work that I don't think can be sensibly finished before squeeze release. Next steps (just opinion): - revert the symbol files change - upload to experimental ASAP - test-rebuild applications against jack2 - in paralell: review the license issues - upload to unstable if all OK I will not revert the symbol file change, but weaken them to only cause warnings (not build failure), when changing. I don't see anything in the jack documentation that would warrant architecture specific symbol files. This means that some warnings will always appear on symbols that should be hidden. And yes, if you coding experts (compared to me) consider the symbol differences between 1.1.x and 1.9.x not worrying, then I will proceed with releasing the current packaging, and postpone polishing the symbol file handling till later :-) That's really hard to tell with that much noise. That noise also makes maintaining the symbol files in future unnecessary hard for my taste. If I run into no more problems then I see no problem in releasing directly to unstable. I.e. no need to first do experimental build. Well, we can do so as well, but I don't think we can use symbol files here as safety guard to check ABI compatibility. That's why I suggested to go via experimental. However, if someone already did a test rebuild of all packages that build-depend on libjack-dev with jack2, then I agree that we should go via unstable directly. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler siret...@tauware.de wrote: On Thu, Apr 08, 2010 at 18:11:39 (CEST), Jonas Smedegaard wrote: On Thu, Apr 08, 2010 at 02:34:37PM +0200, Reinhard Tartler wrote: On Thu, Apr 08, 2010 at 13:06:18 (CEST), Adrian Knoth wrote: On Tue, Apr 06, 2010 at 07:29:51AM +0200, Reinhard Tartler wrote: Can someone fluent in C/C++ please look at this? Perhaps you, Adrian, since you seem most knowledgeable in JACK around here? I think I qualify. I'm not sure if I do. ;) Never used the debian symbol files... I did not expect you to understand the symbol file mechanism, but the underlying library symbols that are extracted by that mechanism. What I believe to have understood but is beyond me to work further on (and that I am hoping you guys could help with) is that C++ code (and C too?) should be able to mark a symbol as private - which the Debian symbol mechanism would then respect. I've been investigating symbol files for FFmpeg, which doesn't really do symbol hiding as well. My conclusion was to not use symbol files of several reasons (the most important one doesn't apply to jack, but anyway) For C++ libraries, I don't see any point in using symbol files until dpkg-gensyms understands unmangled symbols. Working on demangled symbol is just too painful IMO. According to bug #563752, dpkg-gensyms understands them. For jack, I think the amount of symbol files is just too much ATM. First, I'd strongly suggest to hide the symbols. I agree here. Symbol tracking does not make sense when the signal/noise ratio is too high, as in this case. Even if upstream do not maintain such hints, I would be willing to work on applying them as a patch to the Debian packaging, based on canonical documentation (i.e. Doxygen-generated documentation, apparently). But I need someone to help educate me on the syntax of such hints, and whether or not aplying those could affect the resulting code badly (except off course hinting wrongly, so parts of the public API gets hidden). I've done so for FFmpeg 0.6 by introducing a versioning script. While symbol versioning is currently not necessary, I think we can use the mechanism for jack as non-invasive technique as well. AFAIR, it is possible to mark symbols without version tags, so we should be able to retain full binary compatibility with other distros. If versioning script is not going to work for some reason, the other option is to extend the compilations flags to not export ANY symbols by default, and extend the public .h files to only export those functions and globals that are mentioned in the doxygen documentation. As this work is really tedious and hard to get right, I'd strongly suggest to do this work upstream; which means two upstreams in this case. :/ Not really, because we are dropping jack1. And yes, if you coding experts (compared to me) consider the symbol differences between 1.1.x and 1.9.x not worrying, then I will proceed with releasing the current packaging, and postpone polishing the symbol file handling till later :-) That's really hard to tell with that much noise. That noise also makes maintaining the symbol files in future unnecessary hard for my taste. Painful, error-prone and superfluous. Shlibs files are enough for the relatively stable jack API, IMO. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 19:24:23 (CEST), Felipe Sateler wrote: For C++ libraries, I don't see any point in using symbol files until dpkg-gensyms understands unmangled symbols. Working on demangled symbol is just too painful IMO. According to bug #563752, dpkg-gensyms understands them. yes, these changes look very promising, but are not in unstable (yet), and won't make it into ubuntu lucid :-( And yes, if you coding experts (compared to me) consider the symbol differences between 1.1.x and 1.9.x not worrying, then I will proceed with releasing the current packaging, and postpone polishing the symbol file handling till later :-) That's really hard to tell with that much noise. That noise also makes maintaining the symbol files in future unnecessary hard for my taste. Painful, error-prone and superfluous. Shlibs files are enough for the relatively stable jack API, IMO. probably needless to say, but I agree. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 01:24:23PM -0400, Felipe Sateler wrote: On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler siret...@tauware.de For jack, I think the amount of symbol files is just too much ATM. First, I'd strongly suggest to hide the symbols. I agree here. Symbol tracking does not make sense when the signal/noise ratio is too high, as in this case. I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a concern, Reinhard have checked it out and judged it as not worrying, and I am satisfied with that. I do not expect similar noise from here on. If more noise occur due to applied VCS patching, I would want to know, as we then might accidentally include upstream API-breaking changes too new for next upstream stable release. And yes, if you coding experts (compared to me) consider the symbol differences between 1.1.x and 1.9.x not worrying, then I will proceed with releasing the current packaging, and postpone polishing the symbol file handling till later :-) That's really hard to tell with that much noise. That noise also makes maintaining the symbol files in future unnecessary hard for my taste. Painful, error-prone and superfluous. Shlibs files are enough for the relatively stable jack API, IMO. We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
jackd2 in opensuse
Hi! The opensuse jackd maintainer just informed me that he switched from jackd1 to jackd2 on BuildService. OpenSuse 11.3 will follow soon. Looks like we have coordinated acting of distros, here. ;) -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: jackd2 in opensuse
On Thu, Apr 08, 2010 at 09:41:56PM +0200, Adrian Knoth wrote: Hi! The opensuse jackd maintainer just informed me that he switched from jackd1 to jackd2 on BuildService. OpenSuse 11.3 will follow soon. Looks like we have coordinated acting of distros, here. ;) Cool! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 8, 2010 at 15:17, Jonas Smedegaard d...@jones.dk wrote: On Thu, Apr 08, 2010 at 01:24:23PM -0400, Felipe Sateler wrote: On Thu, Apr 8, 2010 at 12:50, Reinhard Tartler siret...@tauware.de For jack, I think the amount of symbol files is just too much ATM. First, I'd strongly suggest to hide the symbols. I agree here. Symbol tracking does not make sense when the signal/noise ratio is too high, as in this case. I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a concern, Reinhard have checked it out and judged it as not worrying, and I am satisfied with that. I do not expect similar noise from here on. If more noise occur due to applied VCS patching, I would want to know, as we then might accidentally include upstream API-breaking changes too new for next upstream stable release. The problem is that when the internal implementation changes, you will get more noise. As an aside, the symbols file is not to ease tracking of symbol changes for the maintainer, but for the packaging system. You need to know *before* applying a patch whether it will take an update to the symbols file, and why. And yes, if you coding experts (compared to me) consider the symbol differences between 1.1.x and 1.9.x not worrying, then I will proceed with releasing the current packaging, and postpone polishing the symbol file handling till later :-) That's really hard to tell with that much noise. That noise also makes maintaining the symbol files in future unnecessary hard for my taste. Painful, error-prone and superfluous. Shlibs files are enough for the relatively stable jack API, IMO. We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. Of course we cannot be certain. But our job as package maintainers is to track that and let the packaging system know, not the other way around. Before merging from upstream you (as in a generic you, the person doing the merge) need to know what API and ABI changes it will contain. And for tracking a relatively stable and noisy library like jack, a shlibs file is enough. The noisy part is important because the packaging system (and perhaps the maintainer) might get confused by the irrelevant symbols. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 21:17:58 (CEST), Jonas Smedegaard wrote: I agree that the *switch* from 1.1.x to 1.9.x is noisy, I raised that as a concern, Reinhard have checked it out and judged it as not worrying, and I am satisfied with that. It seems we are miscommunicating, I don't remember such a statement. I do not expect similar noise from here on. If more noise occur due to applied VCS patching, I would want to know, as we then might accidentally include upstream API-breaking changes too new for next upstream stable release. We seem to talk about different kind of noise. I'm talking about the lines in the symbol files that correspond to symbols that are not part of the export jack API. They will be around until symbol hiding is implemented. We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. The jack API as defined by the doxygen documentation is AFAIUI fairly stable. The exported ABI seems not. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 8, 2010 at 17:22, Reinhard Tartler siret...@tauware.de wrote: We only _assume_ JACK API to be stable - yet we track upstream VCS so should not be certain IMO. The jack API as defined by the doxygen documentation is AFAIUI fairly stable. The exported ABI seems not. The _intended_ exported ABI seems, though. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
I've looked a bit into the hiding thing... and jack2 seems to export 2 kinds of symbols. It exports weak symbols (the standard API), and exports several other symbols as default visibility. I'm guessing that the default symbols are part of the libjackserver API, but for some reason some of them are getting leaked into the client API. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Possible JACK ABI changes between 0.118 and 1.9.5
On Thu, Apr 08, 2010 at 05:55:52PM -0400, Felipe Sateler wrote: I've looked a bit into the hiding thing... and jack2 seems to export 2 kinds of symbols. It exports weak symbols (the standard API), and exports several other symbols as default visibility. I'm guessing that Have you seen this comment in jack.h? /* * NOTE: JACK_WEAK_EXPORT ***MUST*** be used on every function * added to the JACK API after the 0.116.2 release. * * Functions that predate this release are marked with * JACK_WEAK_OPTIONAL_EXPORT which can be defined at compile * time in a variety of ways. The default definition is empty, * so that these symbols get normal linkage. If you wish to * use all JACK symbols with weak linkage, include * jack/weakjack.h before jack.h. */ HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#558502: marked as done (Missing autoreconf to fix 554821 or similar bugs in the future)
Your message dated Fri, 9 Apr 2010 03:04:23 +0200 with message-id m2me5354091004081804jfe5575b2te2d9c150f0a3d...@mail.gmail.com and subject line Missing autoreconf to fix 554821 or similar bugs in the future has caused the Debian Bug report #558502, regarding Missing autoreconf to fix 554821 or similar bugs in the future to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 558502: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558502 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: gavl Version: 1.1.1-2 Severity: minor User: peter.fritzs...@gmx.de Usertags: missing-libtool-update I did a rebuild of all packages which are affected by bug #554821. As it seems your package doesnt do the needed autoreconf needed for libtool. When doing autoreconf or the needed sequence of different autotools/libtool utilities the package should be able to fix the problem automatically. /usr/share/doc/autotools-dev/README.Debian.gz explains it in section Basic summary of packaging source that uses autotools. The build was done in a cowbuild chroot with the patch from #554821 included in /usr/share/aclocal/libtool.m4 and binutils-gold installed. All logs were then greped for -export-symbols-regex and not including -version-script. This should indicate that your package doesnt do the required autoreconf with updating the libtools stuff. A small extra test output test-version-script was added to libtool.m4 and silent mode was disabled in global ltmain.sh so it is easier for me to decide if it was really updated in case libtool doesnt output the ld command to stdout. So if the output and test-version-script is missing then your program doesnt update the files. I am sorry if this is still a false positive. udev 147-5 for example fails completely due to new (unknown) symbols appearing inside the .so, but `autoreconf -fi -I m4` (with libtool.m4 installed on my system with the mentioned patch) fixes the problem. I had to remove a patch with touches Makefile.in, but the rest worked out of the box. Maybe it is better to copy all clean files into a extra directory, run autoreconf inside the directory, build and install everything from that directory and in clean remove that directory. This way the diff.gz should be clean and you still do the necessary autoreconf. A package which does that is g3dviewer. Many other packages like libupnp4 and compizconfig-python just ignore the fact that these changes are included in debian.tar.gz/diff.gz The interesting output inside the log of your program is: /bin/bash ../libtool --tag=CC --mode=link cc -D__GAVL__ -g -O2 -g -Wall -O2 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -export-symbols-regex gavl -version-info 1:0:0 -o libgavl.la -rpath /usr/lib absdiff.lo arith128.lo audioconverter.lo audioformat.lo audioframe.lo audiooptions.lo blend.lo colorspace.lo cputest.lo deinterlace.lo deinterlace_blend.lo deinterlace_copy.lo deinterlace_scale.lo dsp.lo dsputils.lo interleave.lo memcpy.lo mix.lo peakdetector.lo psnr.lo rectangle.lo sampleformat.lo samplerate.lo scale.lo scale_context.lo scale_kernels.lo scale_table.lo time.lo timecode.lo timer.lo transform.lo transform_context.lo transform_table.lo video.lo videoformat.lo videoframe.lo videooptions.lo volume.lo mmx/libgavl_mmx.la mmxext/libgavl_mmxext.la sse/libgavl_sse.la sse2/libgavl_sse2.la sse3/libgavl_sse3.la 3dnow/libgavl_3dnow.la c/libgavl_c.la hq/libgavl_hq.la libgdither/libgdither.la libsamplerate/libsamplerate.la -lm libtool: link: /usr/bin/nm -B .libs/absdiff.o .libs/arith128.o .libs/audioconverter.o .libs/audioformat.o .libs/audioframe.o .libs/audiooptions.o .libs/blend.o .libs/colorspace.o .libs/cputest.o .libs/deinterlace.o .libs/deinterlace_blend.o .libs/deinterlace_copy.o .libs/deinterlace_scale.o .libs/dsp.o .libs/dsputils.o .libs/interleave.o .libs/memcpy.o .libs/mix.o .libs/peakdetector.o .libs/psnr.o .libs/rectangle.o .libs/sampleformat.o .libs/samplerate.o .libs/scale.o .libs/scale_context.o .libs/scale_kernels.o .libs/scale_table.o .libs/time.o .libs/timecode.o .libs/timer.o .libs/transform.o .libs/transform_context.o .libs/transform_table.o .libs/video.o .libs/videoformat.o .libs/videoframe.o .libs/videooptions.o .libs/volume.o mmx/.libs/libgavl_mmx.a mmxext/.libs/libgavl_mmxext.a sse/.libs/libgavl_sse.a sse2/.libs/libgavl_sse2.a sse3/.libs/libgavl_sse3.a 3dnow/.libs/libgavl_3dnow.a c/.libs/libgavl_c.a hq/.libs/libgavl_hq.a libgdither/.libs/libgdither.a
Processing of stk_4.4.2-4_amd64.changes
stk_4.4.2-4_amd64.changes uploaded successfully to localhost along with the files: stk_4.4.2-4.dsc stk_4.4.2-4.diff.gz libstk0-dev_4.4.2-4_amd64.deb libstk0c2a_4.4.2-4_amd64.deb stk_4.4.2-4_amd64.deb stk-doc_4.4.2-4_all.deb Greetings, Your Debian queue daemon (running on host ries.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
stk override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): libstk0-dev_4.4.2-4_amd64.deb: package says section is libdevel, override says sound. Please note that a list of new sections were recently added to the archive: cli-mono, database, debug, fonts, gnu-r, gnustep, haskell, httpd, java, kernel, lisp, localization, ocaml, php, ruby, vcs, video, xfce, zope. At this time a script was used to reclassify packages into these sections. If this is the case, please only reply to this email if the new section is inappropriate, otherwise please update your package at the next upload. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please file a bug against ftp.debian.org and explain why. Please INCLUDE the list of packages as seen above, or we won't be able to deal with your request due to missing information. Please make sure that the subject of the bug you file follows the following format: Subject: override: BINARY1:section/priority, [...], BINARYX:section/priority Include the justification for the change in the body of the mail please. [NB: this is an automatically generated mail; if you already filed a bug and have not received a response yet, please ignore this mail. Your bug needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#569052: marked as done ((stk_4.4.2-3/avr32): FTBFS: Outdated config.{sub,guess})
Your message dated Fri, 09 Apr 2010 01:33:14 +
with message-id e1o035u-00053e...@ries.debian.org
and subject line Bug#569052: fixed in stk 4.4.2-4
has caused the Debian Bug report #569052,
regarding (stk_4.4.2-3/avr32): FTBFS: Outdated config.{sub,guess}
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
569052: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569052
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: stk
Version: 4.4.2-3
Severity: wishlist
User: bradsm...@debian.org
Usertags: avr32
Hi,
Whilst building your package on AVR32, the build failed due to outdated
config.{sub,guess} files.
Full build logs available:
http://buildd.debian-ports.org/build.php?pkg=stkarch=avr32ver=4.4.2-3
Regards,
Bradley Smith
--
Bradley Smith b...@brad-smith.co.uk
Debian GNU/Linux Developer bradsm...@debian.org
GPG: 0xC718D347 D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347
---End Message---
---BeginMessage---
Source: stk
Source-Version: 4.4.2-4
We believe that the bug you reported is fixed in the latest version of
stk, which is due to be installed in the Debian FTP archive:
libstk0-dev_4.4.2-4_amd64.deb
to main/s/stk/libstk0-dev_4.4.2-4_amd64.deb
libstk0c2a_4.4.2-4_amd64.deb
to main/s/stk/libstk0c2a_4.4.2-4_amd64.deb
stk-doc_4.4.2-4_all.deb
to main/s/stk/stk-doc_4.4.2-4_all.deb
stk_4.4.2-4.diff.gz
to main/s/stk/stk_4.4.2-4.diff.gz
stk_4.4.2-4.dsc
to main/s/stk/stk_4.4.2-4.dsc
stk_4.4.2-4_amd64.deb
to main/s/stk/stk_4.4.2-4_amd64.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 569...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Alessio Treglia quadris...@ubuntu.com (supplier of updated stk package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Fri, 09 Apr 2010 03:09:31 +0200
Source: stk
Binary: libstk0-dev libstk0c2a stk stk-doc
Architecture: source amd64 all
Version: 4.4.2-4
Distribution: unstable
Urgency: low
Maintainer: Debian Multimedia Maintainers
pkg-multimedia-maintainers@lists.alioth.debian.org
Changed-By: Alessio Treglia quadris...@ubuntu.com
Description:
libstk0-dev - Sound Synthesis Toolkit (development files)
libstk0c2a - Sound Synthesis Toolkit
stk- Sound Synthesis Toolkit (example applications)
stk-doc- Sound Synthesis Toolkit (documentation)
Closes: 569052
Changes:
stk (4.4.2-4) unstable; urgency=low
.
* Install config.{guess,sub} into the right location (Closes: #569052).
Checksums-Sha1:
2b74b624b013ffa5c251f5b7db73b6952ac7bdad 1418 stk_4.4.2-4.dsc
a3d41cda62ab8b8de3b9bd8dd72ddd906844a6e9 8809 stk_4.4.2-4.diff.gz
ed4133a30336ef2bbdb125791fd07e9b62999549 106518 libstk0-dev_4.4.2-4_amd64.deb
a4d24cc4d54319f7d3363b6e90a5630375297cbb 316388 libstk0c2a_4.4.2-4_amd64.deb
34dfbb14c9c0b7f380e80bc81a005ab6ed04451d 531792 stk_4.4.2-4_amd64.deb
aa4079d2c7f7dff272bb96774bd78ec1d61689d8 1260196 stk-doc_4.4.2-4_all.deb
Checksums-Sha256:
55d380affad9c0a895a892fe562ba70e29b1e4918e41fedfba316494feea3d1e 1418
stk_4.4.2-4.dsc
651260b9f27f0a5a02328ee2b59831be399f8d6c9304631006359c91530fde58 8809
stk_4.4.2-4.diff.gz
98360523d43bfcfaab2b3d75dc14c2db95af93890b8c46b0194dc9eaf4917070 106518
libstk0-dev_4.4.2-4_amd64.deb
e77a11071108dcba7a0c54c7118f4351665b470139fde62e72a0e7d7a48aab88 316388
libstk0c2a_4.4.2-4_amd64.deb
c5ec08da103b57d3d2a77eaf91d849202f75017d46d84264948251143a179459 531792
stk_4.4.2-4_amd64.deb
5b486eb7533d6b999b16b6e78ddd6a0b1d93a8f6b37b0f58f501834e977fe347 1260196
stk-doc_4.4.2-4_all.deb
Files:
b15c6ecd28055c136a20bbedb67b88bf 1418 sound optional stk_4.4.2-4.dsc
7af26edfc21b71a13efa9a88a0c8bdf0 8809 sound optional stk_4.4.2-4.diff.gz
a511a034d18d1bdcb1f088e8713e8931 106518 libdevel optional
libstk0-dev_4.4.2-4_amd64.deb
16b7ea0490f3ca4be515a8a04318d08a 316388 sound optional
libstk0c2a_4.4.2-4_amd64.deb
b40324ba7a02faa850f6de60b5458326 531792 sound optional stk_4.4.2-4_amd64.deb
3ad236ff1247c8d2214bcdcb5520e6dc 1260196 doc optional stk-doc_4.4.2-4_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAku+gN4ACgkQRdSMfNz8P9B/hACeLnjGu7l5WIfATfgZoSyukEMG
Caro friend
São Paulo 9/4/2010 À friend Prezado friend Meu nome e Paulo Aleksandro sou prestador de serviços no setor de TI . Sou prestador de Serviços á 9 anos na área de Informátiva e trabalho com as 3 principais plataformas do mercado (Windows,Linux e Mac) e certificado em duas, windows e linux, em windows possuo a certificação MCSA e em linux possuo a certificação LPIC 201, tambem presto serviços em hardware possuindo curso tecnico e mais de 9 anos de experiencia em lojas e no setor corporativo! Presto serviços Windows integrado com Linux Proxy autenticado com filtro de conteudo padrão NTLM, LDAP ou Basic, Samba, Ftp e muitos outros aplicativos Linux Servidor Dns, Servidor de Hospedagem, Servidor Web, Firewall, Gateway, Balanceador de Carga, VPN, Monitor de Servidres, Servidores de email, controle de entrada e saida de dados por email, filtro de internet, Load Balance, chat, comunicador interno com servidor asterisk de PBX-IP, Servidor Moodle, Joomla, E-commerce, Zimbra, ISPConfig, Cpanel, video conferencia, Voip, Filtro de internet, Filtro de Email, dentre muitos outros serviços em plataforma linux, Windows Servidores de dominio, AD, Dns, Wins, VPN, IIS, Exchange, Isa Server e muitos outros. Virtualização e Paravirtualização (Emulação de servidores) Windows e linux na mesma maquina reduzindo custo de aquisiçao de equipamentos Webdesigner Desenvolvimento de Sistemas e Sites em Flash, PHP, ASP, Sistema de E-commerce, CMS, EAD ,Intranet dentre muitos outros Hardware Montagem, manutenção,e atualização de equipamento para utlização com versoes mais recentes de sistema operacional Software de Controle Chamados Técnicos Com SLA, Redes Montagem de redes, Servidores em Windows e Linux, Cabeamento e projetos de rede, Roteadores, WIFI dentre outras soluçoes Essas são Algumas das empresas onde presto serviços e ambientes Implementados Industria Química UNA -Instalação de firewall, Filtro de internet Autenticado, Relatório de Acesso Com o Nome do Usuário, Shaper Controle de Uso de Link de Internet, VPN Interligando Matriz, Filial e Revendas, Load Balance, Servidor de E-mail Zimbra Ganhos Com Ambiente: Redução de Virus na Rede, Redução de Link de 8mb para 2mega e mantendo a mesma qualidade, redução de custos de Internet e Manutenção COTLOG - Instalação de Filtro de Internet, Relatório de Acesso Por Usuário, Instalação de Servidor de Active Directory com Perfis Moveis, Servidor de Arquivos no Linux, Ganhos Com o Ambiente: Nao desapareceram mais dados da rede, Servidor de Web para sistema nao paresenta mais problema de lentidao, Servidor de Arquivos com backup diario Saquitel Comércios de Plásticos LTDA - Manutenção de Equipamentos e Servidores, Criação de Intranet. Ganhos Com o Ambiente: Redução de Problemas de lentidão, padronização de equipamentos, Intranet com Pesquisa de possiveis melhorias. Saquitel Plast - Manutenção dos computadores e servidor, Montagem de Intranet Ganhos Com o Ambiente: Redução de Problemas de lentidão, padronização de equipamentos, Intranet com Pesquisa de possiveis melhorias. Pekon Condutores e Cabos Elétricos - Manutenção dos computadores e Montagem de um Servidor de Arquivos e Firewall Ganhos Com o Ambiente: Nao desapareceram mais dados da rede, Servidor de Web para sistema nao paresenta mais problema de lentidao, Servidor de Arquivos com backup diario Sky Net World Wide Express - Montagem de Servidor de Banco de Dados Oracle, Servidor de Active Directory, Firewall, Filtro de Internet, Relatórios de Acesso, Shaper, e criação de VPN com Matriz Ganhos Com Ambiente: Redução de Virus na Rede, Redução de Link de 16mb para 4mega e mantendo a mesma qualidade. padronização de equipamentos, e treinamento de Funconários Fábia Empreendimentos Imobiliários - Manutenção de Computadores, Filtro de Internet e E-mail, Relatórios de Acesso a Internet, Firewall Linux Two Brothers Lan House - Instalação de Filtro de Internet, Manutenção de Computadores e Firewall Linux Ganhos Com Ambiente: Redução de Virus na Rede, redução de custos de Manutenção, Padronização de equipamentos, Seu site foi montado em HTML e nao tem animação entre e contato e veja os modelos que temos prontos para todos os segmentos, Email Empresarial Incluso com 7gb de espaço Nao utilize mais @gmail @uol @ig @bol use o seu dominio @seusite.com,br Caso haja Interesse em algum de meus serviços segue meu Contato Para Contratos Treinamento de Ambiente Incluso Valor Hora R$ 65,00 Planos de Contrato 04 Horas 08 Horas 16 Horas 32 Horas Valores 210,00 350,00 450,00650,00 Paulo Aleksandro E-mail: paulo.a...@gmail.com ERL - Engenheiro de Redes Linux EDO - Email Delivery Optimization (Postfix Tunning) Zimbra Administrator LDAP Administrator MCSA 2003 LPIC 201 Tel: (11) 6678-5450 Msn: paulo.a...@hotmail.com www.starconsulting.com.br www.starconsulting.com.br/sites
