package with new soname: questions about .symbols and uploading
Dear mentors, I've packaged a new version of my library package 'libharu'. Since upstream uses a -RELEASE type of version number, I copied this, and this resulted in a libhpdf-2.1.0 package. I've now updated my package to version 2.2.1. It builds these binary packages: libhpdf-2.2.1 - C library for generating pdf files libhpdf-dev - C library for generating pdf files (development files) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libharu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libharu/libharu_2.2.1-1.dsc But I still want to fix the .symbols file. However, I was not able to find how I should do it in this case (new packagename). Should I just generate a new file from scratch (I have not seen incompatible api changes) or refer to the old version number for functions which were available before. Anyway, it's a general concern that I find little advice on how a symbols file should actually look [1] - whether the one I made previously was actually valid - so I was actually considering to perhaps not include a symbols file anymore (better no file than one which is possibly incorrect). So three questions: 1) should I still have a symbols file? 2) what are good references for building/maintaining it? 3) should I recreate it from scratch - or refer to the old version of the package? and one fourth bonus question: One package which I'm not maintaining relies on libharu. If I upload a new version this will need a rebuild. How is this usually handled? Kind regards Johan Van de Wauw [1] eg http://qa.debian.org/cgi-bin/mole/seedsymbols/main seems to be broken -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJOp35k-mGKa7GuzWJRx0SyF4dno4LdZAhVED=42pdysnfc...@mail.gmail.com
Re: RFS: libspctag
On Thu, Jul 14, 2011 at 04:09:49AM +0200, Jérôme SONRIER wrote: Le jeudi 14 juillet 2011, Andreas Rönnquist a écrit : That said - You are upstream too for this package? It would be very nice to provide a upstream changelog - lintian (from unstable) if run as Yes, I'm the upstream maintainer. I didn't provide a changelog because this is the first release, but I will make one for future versions. Just for the record, I always put a First public release changelog entry in the changelog of the, well, first release of my stuff :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. signature.asc Description: Digital signature
Re: package with new soname: questions about .symbols and uploading
But I still want to fix the .symbols file. However, I was not able to find how I should do it in this case (new packagename). Should I just generate a new file from scratch (I have not seen incompatible api changes) or refer to the old version number for functions which were available before. Anyway, it's a general concern that I find little advice on how a symbols file should actually look [1] - whether the one I made previously was actually valid - so I was actually considering to perhaps not include a symbols file anymore (better no file than one which is possibly incorrect). So three questions: 1) should I still have a symbols file? 2) what are good references for building/maintaining it? 3) should I recreate it from scratch - or refer to the old version of the package? While I am no expert on library packaging, I always thought that the main use of the symbol file is to allow building programs that use symbols already present in the old version, to be compiled with the new, and still work with the former. (Eg, if foo@LIBBAR_1.0 is used by a program, and is linked against libbar1 1.2, it would still result in a libbar1 = 1.0 dependency, since it doesn't use any new symbols) But since there's a SONAME change involved, I see no point in symbol files, as the program will need to depend on the new version, if for nothing else, then for the SONAME. Thus, in this case, I'd drop the symbol file, and use dh_makeshlibs -V instead. I don't think symbol files are of any use for libraries that follow this versioning scheme. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ei1tuqoc@balabit.hu
Re: RE : : RFS: autoconf-archive (updated package)
I have done the work needed On Wed, Jul 13, 2011 at 11:17 AM, Kilian Krause kil...@debian.org wrote: Hi Bastien, On Tue, 2011-07-12 at 09:17 +0200, roucaries bastien wrote: Ping ? 1. debian/watch needs fixing to avoid your ugly epoch hack: opts=uversionmangle=s/[-\.]//g \ is the correct way to update Done 2. DEP5 is now at http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?view=markuppathrev=174 Please update in debian/copyright Done 3. Lintian still warns about: E: autoconf-archive source: git-patches-not-exported P: autoconf-archive source: unneeded-build-dep-on-quilt Which seems to be correct as debian/patches is empty except for debian/patches/series. Do you reckon that there should be no patches at all or are they plain missing in your source? They are no patches. It is a bug in gitpkg even after david Bremner patch lintian complain. Bastien Apart from that, IMHO ready to be put into Debian. -- Best regards, Kilian -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazvu9jwf+h4yc8pq3hugom1ykjvqoagc-+zf+0cruw...@mail.gmail.com
Re: package with new soname: questions about .symbols and uploading
On Thu, Jul 14, 2011 at 11:31 AM, Johan Van de Wauw wrote: But I still want to fix the .symbols file. However, I was not able to find how I should do it in this case (new packagename). Symbols files are mainly useful when one SONAME/package name lasts longer than one Debian release cycles. It sounds like your ABI is still changing more frequently than that and you have relatively few reverse dependencies so I wouldn't bother with them at all. 1) should I still have a symbols file? No. 2) what are good references for building/maintaining it? dpkg-gensymbols(1) deb-symbols(5) http://wiki.debian.org/UsingSymbolsFiles 3) should I recreate it from scratch - or refer to the old version of the package? Yep, from scratch. One package which I'm not maintaining relies on libharu. If I upload a new version this will need a rebuild. How is this usually handled? This is known as a transition. Since it is just one package there isn't much of a transition (and thus requires much less work), but in general the steps are: Test build all the reverse deps with the new lib and possibly file bugs. Request a transition slot from the release team with a list of needed binNMUs. Mark the transition bug as blocked by any bugs in reverse deps. Push to get all the blocking bugs closed while waiting for everything to get rebuilt. In your case, just test the reverse dep and request a binNMU for it from the release team if it works or file a bug if not. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6Gj_6Xm5HZaerS-2Nrkye+HGsu75NS0vLxvebt2=mo...@mail.gmail.com
RFS: libharu (updated package)
Dear mentors, I am looking for a sponsor for the new version 2.2.1-1 of my package libharu. It builds these binary packages: (new) libhpdf-2.2.1 - C library for generating pdf files libhpdf-dev - C library for generating pdf files (development files) I've tested the package and lintian does not complain. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libharu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libharu/libharu_2.2.1-1.dsc I would be glad if someone uploaded this package for me. 2 remarks: - dfsg cleaning was necessary in the previous version: this is no longer true because the upstream tarball no longer contains the examples which were causing problems - I've removed the .symbols because it is a bit irrelevant in a package whose name changes when the so-name changes (see discussion on d.mentors: [0]. Kind regards Johan Van de Wauw [0]: http://lists.debian.org/debian-mentors/2011/07/msg00365.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJOp35=qgpgfj2c8f1u4cho8yry0nm9g2i9imbbxocleyey...@mail.gmail.com
Re: RFS: libharu (updated package)
On Thu, Jul 14, 2011 at 1:14 PM, Johan Van de Wauw wrote: - I've removed the .symbols because it is a bit irrelevant in a package whose name changes when the so-name changes (see discussion on d.mentors: [0]. [0]: http://lists.debian.org/debian-mentors/2011/07/msg00365.html Ahh, the package name *always* changes when the SONAME changes, not doing so is a severity serious bug. The reason the symbols file is irrelevant is due to a frequently changing SONAME or one that changes with every upstream version. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GQfMXci0zr_WNzVy3HM2DLQ8S6SS3SVF6NAm3n+b=g...@mail.gmail.com
RFS: kpartsplugin (updated package)
Dear mentors, I am looking for a sponsor for the new version 20110606-1 of my package kpartsplugin. It builds these binary packages: kpartsplugin - Netscape-compatible plugin to embed KDE file-viewers into browser The package appears to be lintian clean: $ lintian -iIEm --pedantic *.deb warning: checksums is deprecated and may be removed in a future Lintian release. The upload would fix these bugs: 632122 Changes: kpartsplugin (20110606-1) unstable; urgency=low . * New upstream release * Added missing libx11-dev in Build-Depends (Closes: #632122) * Copyright file switched to DEP-5 format The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/kpartsplugin - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/kpartsplugin/kpartsplugin_20110606-1.dsc I would be glad if someone uploaded this package for me. Kind regards Michele Gastaldo -- _La libertà non rimane mai la stessa, cambia a seconda della caccia. E se addestrate dei cani a catturarla per voi, è facile che vi riportino una libertà da cani._ (Wu Ming) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5448573e9e80f830a929ec0e7cd46...@inventati.org
Re: RE : : RFS: autoconf-archive (updated package)
On Thu, 14 Jul 2011 12:34:30 +0200, roucaries bastien roucaries.bastien+deb...@gmail.com wrote: They are no patches. It is a bug in gitpkg even after david Bremner patch lintian complain. I'm a bit surprised by that. In any case, try version 0.20 of gitpkg which contains a different fix. If there is still a bug, please report it. d -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrfljdzt.fsf@zancas.localnet
Re: RFS: libharu (updated package)
On Thu, Jul 14, 2011 at 1:18 PM, Paul Wise p...@debian.org wrote: On Thu, Jul 14, 2011 at 1:14 PM, Johan Van de Wauw wrote: - I've removed the .symbols because it is a bit irrelevant in a package whose name changes when the so-name changes (see discussion on d.mentors: [0]. [0]: http://lists.debian.org/debian-mentors/2011/07/msg00365.html Ahh, the package name *always* changes when the SONAME changes, not doing so is a severity serious bug. The reason the symbols file is irrelevant is due to a frequently changing SONAME or one that changes with every upstream version. I agree - bad words from me: since every upstream release causes a soname change anyway. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJOp35=95pTSKJEtq-d=gblkw-_n-r8-m0wtyznhwfo4_be...@mail.gmail.com
Re: RFS: evolution-tray
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.07.2011 13:55, Max Tsepkov wrote: I am looking for a sponsor for my package evolution-tray. For reference, there is also an ongoing discussion on debian-devel regarding the package. See the corresponding thread on [1]. [1] http://lists.debian.org/debian-devel/2011/07/msg00198.html - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOHuZEAAoJEMcrUe6dgPNtpLMP/2SWnFhe+ZB+O/1Uocn9FjOY gOqLXChydMws8Fl7le4uLavQW9LFOqWq6M41zhXNBQX/d+kI/OlECypACBSmdjyL lrdfJtyWuM/Rawyf+wpxHTmKZBSA2ebBajqG6EJAioTZG+YplBX8k+GtJdilqlXa lkVF97W/KEM8HRbnOevUaedKkyij0bSmA6wRNAHUVpTaArYKm8TeJRMF+pw/s5FU ssnu0jyZoAStVIp8+mdWMF6ImEUEpZcc+Tn8zEfRkSrPMj6//uHzefz5OhuSoMIY y8iIoIiiBWrJny1tIZDUp4qY35osBqHz4pZEjH8khQmB1beZG2oKpcqHAjoDYc/1 cFNFFMcVlle1Nam207PWgspaukuN+f1gdRxVdRgBVYfKaaYwOIoSg+BkP4uCkqSu fIEJxD5d0Y/S7fdLbi18KbJ90Fs8FWynr0zx2x+8jGH1FIvGQyP/BqK3IhJ8Kdbi Z9HFOiJNReXd10/po68yEHZSMMhpQzCFRsupVDUvnS7/WDEcGSxVogxR9mA6LQSF uIpmQgKXgrFhZhxh+f45ma7uXkT7nCmD4bPkVX31xmUanU5JnQkonAV3Jfh8203C SSr0oYq22IRqzG9su5W9FFcNjcwROibLSRCBItAJ+j7L8ZH0pqlfdlBNvIonDYOa razusD8vvAle7NsuiJ/F =oaxW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e1ee644.7070...@toell.net
Re: RE : : RFS: autoconf-archive (updated package)
On Thu, Jul 14, 2011 at 1:30 PM, David Bremner brem...@debian.org wrote: On Thu, 14 Jul 2011 12:34:30 +0200, roucaries bastien roucaries.bastien+deb...@gmail.com wrote: They are no patches. It is a bug in gitpkg even after david Bremner patch lintian complain. I'm a bit surprised by that. In any case, try version 0.20 of gitpkg which contains a different fix. If there is still a bug, please report it. I use 0.20, it does not export patches but lintian complain. See the file in mentors. I believe it is a lintian bug. What do you think ? d -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAZxo9fWg+LixnA=ryxp_ezob5dfzpzonznfhdov7uy...@mail.gmail.com
Re: dacco and qdacco packages waiting sponsor
Hi, [...] I have created the new file symbols: the new file is attached to the email. If the file is now correct, then you can review the new version of the package in debian.mentors ( http://mentors.debian.net/debian/pool/main/q/qdacco). I couldn't find any attachment in your email, but the best solution would anyway be to make it part of the package on mentors.d.n :-) Do you know any document that spells out the use of tags in the symbols file ? I want more information on the subject. man dpkg-gensymbols has lot's of information. Best, Michael pgpuC5uFEq2BP.pgp Description: PGP signature
Re: dacco and qdacco packages waiting sponsor
Hi Michael, [...] The question is: how do you generate these files with c++ tags? Is it possible to automatically generate the files? [...] Yes, that can be done almost fully automatically. The main step is piping the current symbols file through c++filt, as in cat qdacco-0.8.2/debian/libqdaccolib0.7.symbols | c++filt then make sure you keep the first line of your current file. The final step is only text mangling: add (c++) in front of each symbol and enclose each symbol in double quotes (as you've taken a look at diagnostics already, you can pick up the exact positioning of all this from there). Thank you very much for the explanation: things always seem more difficult than they are I have created the new file symbols: the new file is attached to the email. If the file is now correct, then you can review the new version of the package in debian.mentors ( http://mentors.debian.net/debian/pool/main/q/qdacco). Do you know any document that spells out the use of tags in the symbols file ? I want more information on the subject. Thank you very much for your help. Regards! I. De Marchi
Re: RE : : RFS: autoconf-archive (updated package)
On Thu, 14 Jul 2011 16:41:05 +0200, roucaries bastien roucaries.bastien+deb...@gmail.com wrote: On Thu, Jul 14, 2011 at 1:30 PM, David Bremner brem...@debian.org wrote: I use 0.20, it does not export patches but lintian complain. See the file in mentors. I believe it is a lintian bug. What do you think ? Certainly E: autoconf-archive source: unknown-file-in-debian-source git-patches is a bug in lintian. For what it is worth, you refer to the wrong bug on mentors.debian.net. This was 607502, also fixed in 2.5.1 (and in 2.5.0~rc1). d -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874o2og32z@convex-new.cs.unb.ca
Re: package with new soname: questions about .symbols and uploading
Johan, On Thu, Jul 14, 2011 at 11:31:04AM +0200, Johan Van de Wauw wrote: I've packaged a new version of my library package 'libharu'. Since upstream uses a -RELEASE type of version number, I copied this, and this resulted in a libhpdf-2.1.0 package. I've now updated my package to version 2.2.1. as far as I understand your comment you suggest that your upsteam doesn't understand the concept of SONAME and SOVER (as part of a stable ABI) and just puts random changes where they are not neccessary but even worse - they are complicating things. If you can confirm that the symbols file for your last version and this version match up perfectly, then the SONAME shouldn't have been bumped in the first place and instead of introducing that broken logic into Debian you might want to start educating your upstream about what an ABI is and how to come up with a stable ABI and enjoy its benefits. I know there is a number of upstreams who plain don't care about API and ABI stability and think as long as they jump about SOVER and SONAME regularily enough this is ok. They usually just haven't bothered looking up details and are quite interested once you talk to them AFAICT. Point is that with this scheme each new release will trigger a new package name for Debian including a forced (binNMU) rebuild of all subsequent packages. This is way more overhead than what should be considered good practice. IMHO it's the far superior way to have subsequent releases follow up using the same SONAME as long as the ABI is a drop-in replacement. That way you can build as many new releases using the same binary package names as will come along and all reverse depends will continue working just fine without any rebuild whatsoever. It builds these binary packages: libhpdf-2.2.1 - C library for generating pdf files libhpdf-dev - C library for generating pdf files (development files) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libharu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libharu/libharu_2.2.1-1.dsc But I still want to fix the .symbols file. However, I was not able to find how I should do it in this case (new packagename). Should I just generate a new file from scratch (I have not seen incompatible api changes) or refer to the old version number for functions which were available before. Anyway, it's a general concern that I find little advice on how a symbols file should actually look [1] - whether the one I made previously was actually valid - so I was actually considering to perhaps not include a symbols file anymore (better no file than one which is possibly incorrect). So three questions: 1) should I still have a symbols file? Yes! By all means. And eventually (depending on the development platform of your upstream) you can even try to convice your upstream to peruse this information if they're too lazy to watch over their ABI during development. 2) what are good references for building/maintaining it? man dpkg-gensymbols and the latest emails of Michael Tautschnig on this topic covering c++ symbols too. You may also want to have a look at http://pkg-kde.alioth.debian.org/symbolfiles.html if your lib is C++. 3) should I recreate it from scratch - or refer to the old version of the package? If the package name is bumped, create a new one is most probably the better way than moving the old one in place and fixing it regarding the ABI changes it'll detect. and one fourth bonus question: One package which I'm not maintaining relies on libharu. If I upload a new version this will need a rebuild. How is this usually handled? File a bug against release.debian.org asking for a binNMU. See http://wiki.debian.org/binNMU for more detail. Anyway, if the package name can remain constant and the ABI is compatible or completely unchanged this is the rebuilding which you will not have to take care of. ;-) -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: gogglesmm
Hi On Wed, 13 Jul 2011 23:28:28 +0100 Michael Tautschnig m...@debian.org wrote: [...] I'm afraid the copyright file isn't yet fully complete: - src/md5.h, src/md5.cpp have a distinct license and copyright holders. - src/GMDBus.h is LGPL v2.1+ - line 11 of debian/copyright should probably say LGPL, not GPL. Should now contain the right information. A few more minor notes: - debian/rules, target clean depends on itself!? This was left from using dpatch. Originally clean1 depended on clean. - lintian has a few more notes, all of which are easy to fix: I: gogglesmm source: quilt-patch-missing-description fox_pkg_config.diff I: gogglesmm source: debian-watch-contains-dh_make-template I: gogglesmm: package-contains-empty-directory usr/sbin/ I: gogglesmm: desktop-entry-contains-encoding-key usr/share/applications/gogglesmm.desktop:2 Encoding [...] I fixed these warnings. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gogglesmm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gogglesmm/gogglesmm_0.12.2-9.dsc Again, thank you for your review. Regards, Hendrik -- Hendrik Rittich signature.asc Description: PGP signature
Re: RE : : RFS: autoconf-archive (updated package)
On Thu, 14 Jul 2011 20:06:06 +0200, roucaries bastien roucaries.bastien+deb...@gmail.com wrote: Not fixed in my case: lintian *.changes || lintian --version E: autoconf-archive source: git-patches-not-exported Lintian v2.5.1 Ah, yes. I agree this is a bug, different than the bug we just fixed in gitpkg. I'm not sure at the moment where this should be fixed. It is not possible for lintian to detect that your git-patches file is trivial, i.e. that it will not result in the export of any patches. On the other hand, it seems like something we should try to support, even if we didn't think about it before. Please file a bug on gitpkg, and we can reassign to lintian if that turns out to be the place to fix it. d -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uxsg0op@convex-new.cs.unb.ca
Re: package with new soname: questions about .symbols and uploading
* Kilian Krause kil...@debian.org, 2011-07-14, 20:34: If you can confirm that the symbols file for your last version and this version match up perfectly, then the SONAME shouldn't have been bumped in the first place Err, no, you can't conclude that ABI wasn't broken just from the fact that symbol lists didn't change. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110714184849.ga6...@jwilk.net
Re: RFS: gogglesmm
Hi, [...] I fixed these warnings. [...] Thanks a lot for quickly addressing all those points! I've now built and uploaded your package. Pending review and acceptance by ftp-masters, it should appear in the archives in a few days! Thanks a lot for your work, Michael pgp6IZX5OAzzy.pgp Description: PGP signature
Re: RFS: kpartsplugin (updated package)
Hi, [...] Changes: kpartsplugin (20110606-1) unstable; urgency=low . * New upstream release * Added missing libx11-dev in Build-Depends (Closes: #632122) * Copyright file switched to DEP-5 format [...] Thanks a lot for updating and improving the package! It's built and uploaded. Thanks a lot for our work, Michael pgpufKG9XGUgR.pgp Description: PGP signature
Re: RFS: assaultcube-data (updated package)
Hi again, [...] Thanks a lot for updating this package. Yet the new non-repacking leaves some doubts to me: - Don't repack anymore. is a nice hint that something has changed, but yet it left me to find this out myself via the debdiff. - Using repacknot1 as version appears to be a cruel hack. Ideally we'd have a new upstream version that could be packaged, but if that doesn't happen soonish, we'll have to live with that hack. (Introducing an epoch doesn't seem like a better solution either...) - Why do server binaries belong to a data package? Isn't that just a hack to avoid a new source package? - The original license appears to disallow re-packaging/splitting, hence there must be some exclusive exception provided to Debian. This is, however, not detailed in the copyright file. Best regards, Michael Hello. - True, I've changed it to read Upstream tarball no longer repacked; binaries not removed since used, would this be reasonably verbose? Ok, cool, that sounds more helpful. - Yeah, 1.1.0.5 is in the works, but when is very uncertain (maybe this year...). I discussed the renaming on IRC (mentors/games) and it seemed like this was the most reasonable solution. Ok, thanks a lot for the info. - Would splitting it into two source packages be better, it seems a tad unnecessary? Upstream distributes one AC package with precompiled binaries and data for compile-less usage (which Debian uses only for data currently), and an AC-source package, which Debian uses to create the packages with the binaries. Since the binaries comes in the upstream tarball which Debian calls -data I guessed it would be best to use this source package as-is.. In this case I do agree that splitting is probably too much of a hassle. However, the name still doesn't seem appropriate. Wouldn't it be good to rename the source package? What about moving to assaultcube-nonfree for the source package name? (Here I'm assuming that the assaultcube-data package was non-free before, is that correct?) Renaming the source package requires the additional step of requesting removal of the previous source package from the archives, but that's doable. - Noted (complicates the current deletion of the binaries as well, I guess), I've sent the question of special permission for the Debian project to the main project people, we'll see where that discussion leads. Given your above information about the assaultcube binary package I'm not sure I understand whether the new repacknot package isn't actually license-compliant as it is unmodified!? Best regards, Michael pgpcorRiCnrGk.pgp Description: PGP signature
Re: RFS: evolution-tray
Thanks to people from debian-devel the package is now ready and lintian clean. Therefore, I'm reposting the RFS. Dear mentors, I am looking for a sponsor for my package evolution-tray. * Package name: evolution-tray Version : 0.0.7-1 Upstream Author : Lucian Langa lucila...@gnome.org * URL : http://gnome.eu.org/evo/index.php/Evolution_Tray * License : GPL2 Section : gnome It builds these binary packages: evolution-tray - Plugin for Evolution to put it in notification area The package appears to be lintian clean. The upload would fix these bugs: 633795 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/e/evolution-tray - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/e/evolution-tray/evolution-tray_0.0.7-1.dsc I would be glad if someone uploaded this package for me. Kind regards Max Tsepkov -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1310702197.16382.42.camel@sewers
Re: package with new soname: questions about .symbols and uploading
Hi Jakub, On Thu, 2011-07-14 at 20:48 +0200, Jakub Wilk wrote: * Kilian Krause kil...@debian.org, 2011-07-14, 20:34: If you can confirm that the symbols file for your last version and this version match up perfectly, then the SONAME shouldn't have been bumped in the first place Err, no, you can't conclude that ABI wasn't broken just from the fact that symbol lists didn't change. Err, of course you're right. I just had the logic inverted and of course if the symbols don't match the ABI is broken - not the opposite. Yet my comment still stands that just putting a new SONAME disregarding of ABI changes is not neccessarily a good thing IMHO. -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
