On 29-07-15 14:29, Sven Geggus wrote: > Sebastiaan Couwenberg wrote: > >> sfcgal has been accepted into the archive > > finally
sfcgal has had a relative short stay in the NEW queue, several others had to wait up to 6 months. >> https://tracker.debian.org/pkg/sfcgal >> >> But unfortunately its unstable C++ symbols caused build failures on most >> architectures: >> >> https://buildd.debian.org/status/package.php?p=sfcgal > > *argh* > > Frankly all this symbols stuff is new to me as up till now everything seemed > to work without such a file as well (at least for my custom in house > packages). Proper library packaging is non-trivial, and required for smooth transitions. I've learned quite a lot about this subject especially since I started to co-mainain gdal. Its split C & C++ symbols make it even more complex. >> You should switch to pkgkde-symbolshelper from the pkg-kde-tools to >> handle the C++ symbols > > OK, I tried to do this in the same way liblas does and pushed changes to > git.debian.org > > I also increased the Version Number from 1.1.0-1 to 1.1.0-2 > > Is this correct? Yes, but incomplete. Sticking to the dch defaults (`dch -i` for a new package revision) will set the distribution to UNRELEASED which you should use until all changes have been be made before the new upload. pkgkde-symbolshelper uses its own symbols file format in which it keeps track of the symbols per architecture. It adds a header to the symbols file like: # SymbolsHelper-Confirmed: 1.1.0 amd64 i386 You therefor need to recreate the symbols file as documented in: http://pkg-kde.alioth.debian.org/symbolfiles.html For C++ libraries like sfcgal we need to upload the first revision to experimental to have the buildds build the package and generate the architecture specific symbols. Once the experimental builds are available you update the symbols for the other architectures with the buildlogs downloaded by pkgkde-getbuildlogs and `pkgkde-symbolshelper batchpatch -v <upstream_version> <log_dir>/*.build`. So you need to prepare a new revision for experimental, for which I suggest to version 1.1.0-2~exp1 to have the experimental revision precede the 1.1.0-2 revision for unstable which will contain the symbols for the other architectures. Uploading new upstream releases to experimental first is always a good idea and strongly encouraged. New upstream releases are likely to contains a SONAME bump and the library package rename to match it will cause the package into NEW again. Uploading to experimental prevents the package from being accepted into unstable at an unfortunate time (e.g. blocking an ongoing transition because of outdated dependencies, or starting an uncoordinated transition with its SONAME bump). Transitions should always be staged in experimental first, the automated transition tracker will pick up the new library packages in experimental and setup a tracker. Even without a SONAME bump uploading to experimental first will prevent RC bugs on your package in unstable when they fail to build on one or more of the ports. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
