Bug#771838: [liblensfun0] Please package new upstream version
Hallöchen! Pino Toscano writes: > In data venerdì 8 gennaio 2016 14:41:58, Torsten Bronger ha scritto: > > [...] > >> If there is only one ABI version of lensfun installed, this would >> work. If you want to make possible that liblensfunM can be >> installed locally parallely to liblensfunN, you need to put the >> database format version (not the ABI number) in the -data >> package. > > I see, although often is the database format version going to be > bumped? Say only between lensfun x.y.z to x.(y+1), or even for .z > releases? Currently, Lensfun is under heavy development. It is getting rid of old mistakes and heading towards version 1.0. Then, I expect things to settle down quickly. To answer your question, Lensfun does not have a policy for this (yet). So far, versioning has been without clear rules. But there is a proposal in the inbox of its maintainer to declare "z" as a clear patch release, so no ABI or DB changes. In contrast, a change in "y" may change both. > [...] > > Another solution could be double versioning the data, by library > SONAME and database version, > e.g. /usr/share/lensfun_$ABI/version_$DB/, which could allow to > have liblensfunN and liblensfunN-data, parallel-installable aside > each other SOVERSION. This would mean quite a bit of new developing and testing. If possible, I'd like to avoid it. Besides, there is a conceptual ugliness that the DB files do not depend on the ABI version; one would end up with duplicates. > (Btw, are you an upstream developer? If so, may I contact you > outside of this bug for a couple of things to be fixed?) Yes, I am a developer, and everyone may contact me directly for Lensfun issues, or use the bug tracker, for that matter. Regards, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
Bug#791388: [liblensfun0] Please package new upstream version
Hallöchen! Pino Toscano writes: > [...] > > In data domenica 15 novembre 2015 20:55:54, Torsten Bronger ha scritto: > > [...] > >> We suggest to count the database format version in the Debian >> package name as it is common for libraries: lensfun-data1, >> lensfun-data2, etc. > > Hm, on a Debian system you don't have multiple versions of lensfun > though, i.e. only one liblensfunN, so that version has just one > version of the data; hence, if I make liblensfunN x.y.z depend on > liblensfun-data >= x.y.z, that should ensure the library has the > data it needs, no? If there is only one ABI version of lensfun installed, this would work. If you want to make possible that liblensfunM can be installed locally parallely to liblensfunN, you need to put the database format version (not the ABI number) in the -data package. (Also note that the upcoming major Lensfun release will not be able to read older database versions. But this only makes the comparison expression a little bit longer.) > From what I see, changes in the data of a library (as long as > those data are accessed by the library and only by that) should > not matter to users of the library itself. This is correct. At least, if people read directly the library files, they are on their own. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
Bug#771838: [liblensfun0] New upstream version
Hallöchen! Evgeni Golov writes: > On Wed, Aug 05, 2015 at 11:13:33PM +0200, Guus Sliepen wrote: > >> [...] >> >> Ok, then I will cancel the current delayed upload and prepare one >> with a version from git, and inform all reverse dependencies of >> the impending change. Unless the real maintainers wake up of >> course. > > was there any progress on this? I've not seen anything in the > pkg-kde SVN. (asking with my gimp-lensfun maintainer hat on, as > the new g-l release needs newer lensfun) > > would be willing to help, not liking maintaining libs, though ;) Well, Lensfun 0.3.2 passed the buck to the Debian maintainers. FWIW, there is a branch debian-packaging in the original Lensfun Git repo, in which the Lensfun maintainer made a provisional packaging to see whether the Lensfun code and especially the build system are Debian-compatible. It is a throw-away branch by people not really famliar with Debian packaging guidelines, but it may serve as a starting point. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
Bug#791388: [liblensfun0] Please package new upstream version
Hallöchen! Lensfun just released a version 0.3.2. Changes in the build system are intended to make Debian packaging easy. Moreover, not only the library file is properly versioned (liblensfun.so.x), the same is now implemented for the database itself. Multiple database version can live happily together on the same filesystem. This is necessary because every binary library depends on a particular file format of the database, and this file format may change over time, independently of the ABI version. We suggest to count the database format version in the Debian package name as it is common for libraries: lensfun-data1, lensfun-data2, etc. Regards, Torsten Bronger. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
Bug#791388: NMU uploaded to DELAYED/14 queue
Hallöchen! Roman is right. FWIW, there is a plea for help with questions regarding packaging at https://bugs.launchpad.net/ubuntu/+source/lensfun/+bug/1455216. It would be nice if we could sort this out quickly, since not much is still needed. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#214729: Bug reports for texinfo (and 2 wishes)
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.bugs.general,gmane.comp.tex.texinfo.bugs as well. Hallöchen! Norbert Preining [EMAIL PROTECTED] writes: Hi Karl! On Mon, 06 Feb 2006, Karl Berry wrote: WIth HTML 4.01 Transitional for texinfo.html I get only 4 errors. Just out of curiousity, what are those four errors? Please see yourself: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.logic.at%2Fpeople%2Fpreining%2Ftexinfo.htmlcharset=%28detect+automatically%29doctype=HTML+4.01+Transitional or shorter http://tinyurl.com/cm93p the errors are: [...] Line 9322 column 24: document type does not allow element UL here; missing one of MAP, IFRAME, BUTTON start-tag. ul class=listoffloats @display (and possibly even @example) should not be a pre but a div. This solves three of the errors. The remaining one is cosmetical. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
