Re: Bug#582238: libebml: New upstream release 0.8.0
On Wed, Jun 09, 2010 at 10:39:36 (CEST), Fabian Greffrath wrote: > Am 09.06.2010 09:51, schrieb Fabian Greffrath: >> In this specific case, we could even drop the autotools-dev hack. Both >> config.sub and config.guess are new enough. ;) > > Done. uploaded. -- 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: Bug#582238: libebml: New upstream release 0.8.0
Am 09.06.2010 09:51, schrieb Fabian Greffrath: In this specific case, we could even drop the autotools-dev hack. Both config.sub and config.guess are new enough. ;) Done. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Wed, Jun 09, 2010 at 09:51:12 (CEST), Fabian Greffrath wrote: > Am 09.06.2010 09:40, schrieb Reinhard Tartler: >> it seems that the build dependencies are not strict enough. BTW, would > > He? The package clearly Build-Depends on the version of autotools-dev > which introduced the debhelper addon. right, my bad. >> it be feasible instead of tightening the build dependencies to change >> the packaging in a way that allows building on debian stable? > > Sure, that's possible with some effort. But I consider that > counter-productive. There is so much exciting development going on in > unstable and I think it would be sad if we couldn't make use of > it. Furthermore, it's clearly not the goal of unstable to remain > compatible with stable in order to serve as a source for backports. Sure, I agree. but please also understand that my current workflow includes building them on a machine running debian stable in a unstable chroot with schroot. In this process, I first create a source package outside the chroot, which is then used as basis. By requiring features from unstable *even for building the source package*, you make it an additional efford for me to sponsor the package. Hm. perhaps I should build the source package as well in the chroot. I will revisit my script, maybe its just a minor modification. > In this specific case, we could even drop the autotools-dev hack. Both > config.sub and config.guess are new enough. ;) thanks, please do. -- 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: Bug#582238: libebml: New upstream release 0.8.0
Am 09.06.2010 09:40, schrieb Reinhard Tartler: it seems that the build dependencies are not strict enough. BTW, would He? The package clearly Build-Depends on the version of autotools-dev which introduced the debhelper addon. it be feasible instead of tightening the build dependencies to change the packaging in a way that allows building on debian stable? Sure, that's possible with some effort. But I consider that counter-productive. There is so much exciting development going on in unstable and I think it would be sad if we couldn't make use of it. Furthermore, it's clearly not the goal of unstable to remain compatible with stable in order to serve as a source for backports. In this specific case, we could even drop the autotools-dev hack. Both config.sub and config.guess are new enough. ;) - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Wed, Jun 09, 2010 at 09:24:53 (CEST), Fabian Greffrath wrote: > Am 09.06.2010 06:47, schrieb Reinhard Tartler: >> done. thanks for adpting libebml! > > No problem! > > Would you mind uploading libmms, too, please? $ env LANG=C git-buildpackage -S dpkg-buildpackage -rfakeroot -d -us -uc -i -S dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package libmms dpkg-buildpackage: source version 0.6-1 dpkg-buildpackage: source changed by Fabian Greffrath fakeroot debian/rules clean dh --with autotools-dev,quilt clean dh: unable to load addon autotools-dev: Can't locate Debian/Debhelper/Sequence/autotools_dev.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 8) line 2. BEGIN failed--compilation aborted at (eval 8) line 2. make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 it seems that the build dependencies are not strict enough. BTW, would it be feasible instead of tightening the build dependencies to change the packaging in a way that allows building on debian stable? -- 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: Bug#582238: libebml: New upstream release 0.8.0
Am 09.06.2010 06:47, schrieb Reinhard Tartler: done. thanks for adpting libebml! No problem! Would you mind uploading libmms, too, please? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Tue, Jun 08, 2010 at 21:48:14 (CEST), Fabian Greffrath wrote: >> This conflicts happened because upstream now *removed* its debian/ >> directory. git notices this and tries to apply this change to >> 'master'. This is of course wrong and needs to be undone: >> >> $ git merge upstream >> $ git reset master debian/ >> >> this resets all files under the directory debian to the state that was >> previously in master. >> >> moreover, I've switched to package to source format 3.0 (quilt), so >> that we can properly handle orig.tar.bz2 tarballs. Bug #566993 is a >> bit annoying here, but can be avoided by mentioning that explicitly >> in debian/gbp.conf. More annoyingly, stable's git-buildpackage doesn't support this, but luckily, backports.org provides a copy that does work. > Thanks, Reinhard. > > I've converted the package to dh 7, bumped the library soname and made > it lintian clean, so I consider it ready for upload to experimental. done. thanks for adpting libebml! -- 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: Bug#582238: libebml: New upstream release 0.8.0
> done. > > This conflicts happened because upstream now *removed* its debian/ > directory. git notices this and tries to apply this change to > 'master'. This is of course wrong and needs to be undone: > > $ git merge upstream > $ git reset master debian/ > > this resets all files under the directory debian to the state that was > previously in master. > > moreover, I've switched to package to source format 3.0 (quilt), so > that > we can properly handle orig.tar.bz2 tarballs. Bug #566993 is a bit > annoying here, but can be avoided by mentioning that explicitly in > debian/gbp.conf. Thanks, Reinhard. I've converted the package to dh 7, bumped the library soname and made it lintian clean, so I consider it ready for upload to experimental. Cheers, Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Mon, Jun 07, 2010 at 22:27:41 (CEST), Fabian Greffrath wrote: > This evening I've spent more than one hour getting the newly released > libebml 1.0 merged into our GIT repository - without success. F**king > git-import-orig always complains about file conflicts in the debian/ > directory. How I *hate* debian/ directories in upstream tarballs and > bz2-only upstream tarballs, too - libebml has both! > > So, please someone help me getting git-import-orig to do what I want it > to do. I'd like to get this package in shape and targetted at > experimental within the next days. done. This conflicts happened because upstream now *removed* its debian/ directory. git notices this and tries to apply this change to 'master'. This is of course wrong and needs to be undone: $ git merge upstream $ git reset master debian/ this resets all files under the directory debian to the state that was previously in master. moreover, I've switched to package to source format 3.0 (quilt), so that we can properly handle orig.tar.bz2 tarballs. Bug #566993 is a bit annoying here, but can be avoided by mentioning that explicitly in debian/gbp.conf. -- 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: Bug#582238: libebml: New upstream release 0.8.0
This evening I've spent more than one hour getting the newly released libebml 1.0 merged into our GIT repository - without success. F**king git-import-orig always complains about file conflicts in the debian/ directory. How I *hate* debian/ directories in upstream tarballs and bz2-only upstream tarballs, too - libebml has both! So, please someone help me getting git-import-orig to do what I want it to do. I'd like to get this package in shape and targetted at experimental within the next days. Thanks, Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
Am 01.06.2010 15:23, schrieb Reinhard Tartler: not sure, experimental is obviously a safe choice. talking to upstream seems a good idea to me as well. Fabian, can you perhaps contact upstream and ask on their opinion here? Obviously this issue has already been brought up upstream and according to this reply http://lists.matroska.org/pipermail/matroska-devel/2010-May/003657.html libebml 0.8.x and libmatroska 0.9.x cleraly disqualify as candidates for Squeeze. :( - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Di, Jun 01, 2010 at 15:18:28 (CEST), Fabian Greffrath wrote: > Am 29.05.2010 12:46, schrieb Reinhard Tartler: >> I'll finish the libebml version upgrade and upload, but please give me a >> few days. > > The new libebml seems to introduce quite some backwards-incompatible > changes to the API (judging from the symbols file diff you posted > recently). Is this new library still targetted at Squeeze or should we > prepare an upload to experimental and keep current libebml/libmatroska > in Squeeze untouched? not sure, experimental is obviously a safe choice. talking to upstream seems a good idea to me as well. Fabian, can you perhaps contact upstream and ask on their opinion here? -- 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: Bug#582238: libebml: New upstream release 0.8.0
Am 29.05.2010 12:46, schrieb Reinhard Tartler: I'll finish the libebml version upgrade and upload, but please give me a few days. The new libebml seems to introduce quite some backwards-incompatible changes to the API (judging from the symbols file diff you posted recently). Is this new library still targetted at Squeeze or should we prepare an upload to experimental and keep current libebml/libmatroska in Squeeze untouched? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Sa, Mai 29, 2010 at 18:18:17 (CEST), Jonas Smedegaard wrote: IMHO an excellent reason to use a symbols file! >>> >>> Good idea. >> >>actually, not, this is a c++ lib. >> >> I know that dpkg-gensymbols in unstable supports c++ unmangled symbol >> names, but I cannot figure out how to make it create templates with >> unmangled symboles. I'm certainly not going to do this step by hand! >> >>Jonas, do you know how to do that? > > Not that I am expert on the subject, but a quick googling seems to > indicate that filtering through c++filt (part of the binutils package) > should do the trick. Okay, for educational purposes, I've done this excercise. Find the symbol file attached to this email, which I've generated on the basis of the version in unstable. On the basis of current master, I've generated a symbol diff, which I've attached as well: --- debian/libebml0.symbols (libebml0_0.8.0-1_i386) +++ dpkg-gensymbolsv04RjB 2010-05-29 16:52:18.0 + @@ -1,4 +1,54 @@ libebml.so.0 libebml0 #MINVER# + _zn7libebml10ebmlmaster6removeern9__gnu_cxx17__normal_iteratorippns_11ebmlelementest6vectoris4_sais4_e...@base 0.8.0-1 + _zn7libebml10ebmlmaster6removeerst16reverse_iteratorin9__gnu_cxx17__normal_iteratorippns_11ebmlelementest6vectoris5_sais5_ee...@base 0.8.0-1 + _zn7libebml10ebmlstring15setdefaultvaluee...@base 0.8.0-1 + _zn7libebml10ebmlstringaser...@base 0.8.0-1 + _zn7libebml12emaxidlengthc...@base 0.8.0-1 + _zn7libebml12emaxidlengthc...@base 0.8.0-1 + _zn7libebml12ereadversionc...@base 0.8.0-1 + _zn7libebml12ereadversionc...@base 0.8.0-1 + _zn7libebml12ebmlsinteger14setdefaultsiz...@base 0.8.0-1 + _zn7libebml12ebmluinteger14setdefaultsiz...@base 0.8.0-1 + _zn7libebml12ebmluinteger15setdefaultvalu...@base 0.8.0-1 + _zn7libebml13ebmlcallbacksc1epfrns_11ebmlelementeverkns_6ebmlidepkcrkns_19ebmlsemanticconte...@base 0.8.0-1 + _zn7libebml13ebmlcallbacksc2epfrns_11ebmlelementeverkns_6ebmlidepkcrkns_19ebmlsemanticconte...@base 0.8.0-1 + _zn7libebml14emaxsizelengthc...@base 0.8.0-1 + _zn7libebml14emaxsizelengthc...@base 0.8.0-1 + _zn7libebml15edoctypeversionc...@base 0.8.0-1 + _zn7libebml15edoctypeversionc...@base 0.8.0-1 + _zn7libebml17ebmlunicodestring15setdefaultvalueerns_9utfstri...@base 0.8.0-1 + _zn7libebml18context_ebmlglob...@base 0.8.0-1 + _zn7libebml19edoctypereadversionc...@base 0.8.0-1 + _zn7libebml19edoctypereadversionc...@base 0.8.0-1 + _zn7libebml8edoctypec...@base 0.8.0-1 + _zn7libebml8edoctypec...@base 0.8.0-1 + _zn7libebml8eversionc...@base 0.8.0-1 + _zn7libebml8eversionc...@base 0.8.0-1 + _zn7libebml9ebmldummy6creat...@base 0.8.0-1 + _zn7libebml9ebmlfloat15setdefaultvalu...@base 0.8.0-1 + _znk7libebml10ebmlbinary12validatesiz...@base 0.8.0-1 + _znk7libebml10ebmlstring10defaultva...@base 0.8.0-1 + _znk7libebml11ebmlelement13issmallerthanepk...@base 0.8.0-1 + _znk7libebml12emaxidlength13createelemen...@base 0.8.0-1 + _znk7libebml12ereadversion13createelemen...@base 0.8.0-1 + _znk7libebml12ebmlsinteger13issmallerthanepkns_11ebmleleme...@base 0.8.0-1 + _znk7libebml12ebmluinteger10defaultva...@base 0.8.0-1 + _znk7libebml12ebmluinteger13issmallerthanepkns_11ebmleleme...@base 0.8.0-1 + _znk7libebml14emaxsizelength13createelemen...@base 0.8.0-1 + _znk7libebml15edoctypeversion13createelemen...@base 0.8.0-1 + _znk7libebml17ebmlunicodestring10defaultva...@base 0.8.0-1 + _znk7libebml19edoctypereadversion13createelemen...@base 0.8.0-1 + _znk7libebml19ebmlsemanticcontext11getsemanti...@base 0.8.0-1 + _znk7libebml8edoctype13createelemen...@base 0.8.0-1 + _znk7libebml8eversion13createelemen...@base 0.8.0-1 + _znk7libebml8ebmldate13issmallerthanepkns_11ebmleleme...@base 0.8.0-1 + _znk7libebml8ebmlhead13createelemen...@base 0.8.0-1 + _znk7libebml8ebmlvoid13createelemen...@base 0.8.0-1 + _znk7libebml9ebmlcrc3213createelemen...@base 0.8.0-1 + _znk7libebml9ebmldummy13createelemen...@base 0.8.0-1 + _znk7libebml9ebmlfloat10defaultva...@base 0.8.0-1 + _znk7libebml9ebmlfloat13issmallerthanepkns_11ebmleleme...@base 0.8.0-1 + _znst6vectoripn7libebml11ebmlelementesais2_ee5eraseen9__gnu_cxx17__normal_iteratorips2_s4...@base 0.8.0-1 (c++)"char* std::basic_string, std::allocator >::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag)@Base" 0.7.7~ (c++)"libebml::ADbg::ADbg(int)@Base" 0.7.7~ (c++)"libebml::ADbg::OutPut(char const*, ...) co...@base" 0.7.7~ @@ -26,53 +76,53 @@ (c++)"libebml::EDocTypeReadVersion::Generic() co...@base" 0.7.7~ (c++)"libebml::EDocTypeReadVersion::operator libebml::EbmlId const&() co...@base" 0.7.7~ (c++)"libebml::EDocTypeReadVersion::~EDocTypeReadVersion()@Base" 0.7.7~ - (c++)"libebml::edoctypereadversion_cont...@base" 0.7.7~ - (c++)"libebml::edoctypereadversion_th...@base" 0.7.7~ +#MISSING: 0.8.0-1# (c++)"libebml::edoctypereadversion_cont...@base" 0.7.7~ +#MISSING: 0.8.0-1# (c++)"libebml::edoctypereadversion_th...@base" 0.7.7~ (c++)"libebml::EDocTypeVersion::classin...@base" 0.7.7~ (c++)"libebml::EDocTypeVersion::Clone() co...@base" 0.7.7~ (c++)"li
Re: Bug#582238: libebml: New upstream release 0.8.0
On Sat, May 29, 2010 at 05:41:40PM +0200, Reinhard Tartler wrote: On Sa, Mai 29, 2010 at 12:46:43 (CEST), Reinhard Tartler wrote: On Sa, Mai 29, 2010 at 12:15:20 (CEST), Jonas Smedegaard wrote: On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via "dh_makeshlibs -V"). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. IMHO an excellent reason to use a symbols file! Good idea. actually, not, this is a c++ lib. I know that dpkg-gensymbols in unstable supports c++ unmangled symbol names, but I cannot figure out how to make it create templates with unmangled symboles. I'm certainly not going to do this step by hand! Jonas, do you know how to do that? Not that I am expert on the subject, but a quick googling seems to indicate that filtering through c++filt (part of the binutils package) should do the trick. - 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: Bug#582238: libebml: New upstream release 0.8.0
On Sa, Mai 29, 2010 at 12:46:43 (CEST), Reinhard Tartler wrote: > On Sa, Mai 29, 2010 at 12:15:20 (CEST), Jonas Smedegaard wrote: > >> On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: >>>On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: > I have imported libebml into the team's git on alioth and merged the > new upstream. I'm new to library packaging, but will solicit > assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via "dh_makeshlibs -V"). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. >>> >>>I did not notice. Thank you for pointing it out. >> >> IMHO an excellent reason to use a symbols file! > > Good idea. actually, not, this is a c++ lib. I know that dpkg-gensymbols in unstable supports c++ unmangled symbol names, but I cannot figure out how to make it create templates with unmangled symboles. I'm certainly not going to do this step by hand! Jonas, do you know how to do that? If not, I think the package is good to test and upload after debian/changelog has been updated. -- 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: Bug#582238: libebml: New upstream release 0.8.0
On Sa, Mai 29, 2010 at 12:15:20 (CEST), Jonas Smedegaard wrote: > On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: >>On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: >>> Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. >>> >>> Thanks for taking care of libebml. >>> >>> Did you notice the many changes to the exported headers? Most >>> probably you should raise the shlibs information (e.g. via >>> "dh_makeshlibs -V"). If we are unlucky, upstream even modified the >>> exported ABI, which would mean we need to deviate from upstream and >>> raise the library SONAME. >> >>I did not notice. Thank you for pointing it out. > > IMHO an excellent reason to use a symbols file! Good idea. I'll finish the libebml version upgrade and upload, but please give me a few days. -- 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: Bug#582238: libebml: New upstream release 0.8.0
On Fri, May 28, 2010 at 08:46:07AM -0400, Eric Dantan Rzewnicki wrote: On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via "dh_makeshlibs -V"). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. IMHO an excellent reason to use a symbols file! - 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: Bug#582238: libebml: New upstream release 0.8.0
On Fri, May 28, 2010 at 09:24, Fabian Greffrath wrote: > Am 28.05.2010 15:21, schrieb Fabian Greffrath: >> >> released on such an irregular basis). If the ABI has changed as well, we >> can drop modifying the dh_makeshlibs call and need to force bump the >> library's SONAME instead. This will require a litle patching and an >> additional call to autoreconf. I feel, however, unable to justifiy ABI >> changes from merely looking at header files, though. > > Note that this case will also trigger a library transition, which may be > considered "undesired" by the release team given the approaching Squeeze > freeze. Note that if the ABI has changed incompatibly, it is the only available choice (or not uploading).I will try to look at it when I get some time, maybe I can be of help. -- 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: Bug#582238: libebml: New upstream release 0.8.0
Am 28.05.2010 15:21, schrieb Fabian Greffrath: released on such an irregular basis). If the ABI has changed as well, we can drop modifying the dh_makeshlibs call and need to force bump the library's SONAME instead. This will require a litle patching and an additional call to autoreconf. I feel, however, unable to justifiy ABI changes from merely looking at header files, though. Note that this case will also trigger a library transition, which may be considered "undesired" by the release team given the approaching Squeeze freeze. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
Am 28.05.2010 14:46, schrieb Eric Dantan Rzewnicki: I brought this package over to the team's git from the old svn so that we can all work on it together. Please do what you think is right with it if you have time and interest. (that goes for anyone else who cares, too, of course.) We need to figure out if the library's ABI has changed along with the API. If not, it is sufficient to modify the call to dh_makeshlibs in debian/rules to point to the current upstream version (I do not think it makes sense to introduce a symbols file for a library like this, which (1) noone in the team seems to know very much about and (2) that is released on such an irregular basis). If the ABI has changed as well, we can drop modifying the dh_makeshlibs call and need to force bump the library's SONAME instead. This will require a litle patching and an additional call to autoreconf. I feel, however, unable to justifiy ABI changes from merely looking at header files, though. Which seemed to take care of it. But, I'm happy to be educated about whether I should have done something different or additional. It would be easier to switch to the new "3.0 (quilt)" source format which automatically overrides upstream's debian/ directory by the one provided by the packaging. However, AFAICT it is still not clear how to proceed with this new format within the team. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
On Fri, May 28, 2010 at 01:44:07PM +0200, Fabian Greffrath wrote: > Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: >> I have imported libebml into the team's git on alioth and merged the new >> upstream. I'm new to library packaging, but will solicit assistance from >> other team members to make this happen. > > Thanks for taking care of libebml. > > Did you notice the many changes to the exported headers? Most probably > you should raise the shlibs information (e.g. via "dh_makeshlibs -V"). > If we are unlucky, upstream even modified the exported ABI, which would > mean we need to deviate from upstream and raise the library SONAME. I did not notice. Thank you for pointing it out. I will definitely need help like this with library packaging and will look at the issue you raise. That said ... I brought this package over to the team's git from the old svn so that we can all work on it together. Please do what you think is right with it if you have time and interest. (that goes for anyone else who cares, too, of course.) > How did you handle the debian/ directory in the upstream tarball, i.e. > how did you manage it to not override the one used for packaging in > Debian? On advice from others in irc: 16:46 < siretart> edrz: try 'git checkout master debian/' to ignore upstream changes to debian/ Which seemed to take care of it. But, I'm happy to be educated about whether I should have done something different or additional. Thanks for the help, edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#582238: libebml: New upstream release 0.8.0
Am 27.05.2010 23:08, schrieb Eric Dantan Rzewnicki: I have imported libebml into the team's git on alioth and merged the new upstream. I'm new to library packaging, but will solicit assistance from other team members to make this happen. Thanks for taking care of libebml. Did you notice the many changes to the exported headers? Most probably you should raise the shlibs information (e.g. via "dh_makeshlibs -V"). If we are unlucky, upstream even modified the exported ABI, which would mean we need to deviate from upstream and raise the library SONAME. How did you handle the debian/ directory in the upstream tarball, i.e. how did you manage it to not override the one used for packaging in Debian? - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
