Bug#971015: RFS: vim-ultisnips/3.1-3.1 [NMU] [RC] -- snippet solution for Vim
Control: tags -1 moreinfo On Sat, 26 Sep 2020 11:38:49 +0300 Nicholas Guriev wrote: > Package: sponsorship-requests > Severity: important > Control: block 938777 by -1 > X-Debbugs-CC: Debian Vim Maintainers > X-Debbugs-CC: Michael Fladischer > > Dear mentors, > > I am looking for a sponsor for my package "vim-ultisnips": > > * Package name: vim-ultisnips >Version : 3.1-3.1 >Upstream Author : Holger Rapp > * URL : https://github.com/SirVer/ultisnips > * License : GPL-3+ > * Vcs : https://salsa.debian.org/vim-team/vim-ultisnips >Section : editors > > It builds those binary packages: > > vim-ultisnips - snippet solution for Vim > > To access further information about this package, please visit the following URL: > > https://mentors.debian.net/package/vim-ultisnips/ > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/v/vim-ultisnips/vim-ultisnips_3.1-3.1.dsc > > Or you can see diff in recently imported Git project at salsa.d.o: > > https://salsa.debian.org/vim-team/vim-ultisnips/-/commit/01d9924e156a02d3d43d1997055a53b7405fed93 > > Changes since the last upload: > > vim-ultisnips (3.1-3.1) unstable; urgency=medium > . (...) >* Move packaging repository to a new GitLab instance at salsa.debian.org. Did you talk with the maintainer about that change and he ACKED it? Otherwise it is inappropiate. For once, it was collab-maint before, so it should be the Debian namespace. Also, Michael is not member of the new repo, so he would loose access. If you want to have it in the vim team, you need to either an ACK by Michael or do an ITS. -- tobi
Bug#971248: closing 971248
close 971248 # thanks has been uploaded.
Bug#942884: Bug#971395: RFS: zipios++/2.2.5.0-1 -- small C++ library for reading zip files (documents)
Control: reopen 942884 Control: forcemerge 942884 971395 Control: tags -1 moreinfo # please do not reopen new bugs if the old one was not sponsored. # -- otherwise context is lost. On Tue, Sep 29, 2020 at 10:17:31PM +0200, François Mazen wrote: > Changes since the last upload: > > zipios++ (2.2.5.0-1) unstable; urgency=high (...) . >* Rename library package from libzipios++0v5 to libzipios2 This starts a library transision: You need to upload it to experimental first. See: https://wiki.debian.org/Teams/ReleaseTeam/Transitions (Did not check the package otherwise) -- tobi
Bug#971395: RFS: zipios++/2.2.5.0-1 -- small C++ library for reading zip files (documents)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zipios++": * Package name: zipios++ Version : 2.2.5.0-1 Upstream Author : Thomas Sondergaard * URL : http://zipios.sourceforge.net/ * License : LGPL-2+ * Vcs : https://salsa.debian.org/debian/zipios Section : devel It builds those binary packages: libzipios-dev - small C++ library for reading zip files (development) libzipios2 - small C++ library for reading zip files (library) libzipios-doc - small C++ library for reading zip files (documents) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zipios++/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zipios++/zipios++_2.2.5.0-1.dsc Changes since the last upload: zipios++ (2.2.5.0-1) unstable; urgency=high . * Import new upstream release (Closes: #834171). * Rename library package from libzipios++0v5 to libzipios2 * Add watch file * Fix reproducible issue with doxygen documentation * Add autopkgtest * Add upstream metadata * Bump standard version to 4.5.0 * Forward patches to upstream * Remove documentation duplicate files * Update debhelper compatibility to 13 and ignore uninstalled test binaries. * Fix privacy breach in html documentation. Regards, signature.asc Description: This is a digitally signed message part
Re: Verify the library transition
On Tue, Sep 29, 2020 at 9:59 AM Andrey Rahmatullin wrote: > > On Tue, Sep 29, 2020 at 09:41:58AM -0400, Tong Sun wrote: > > On Tue, Sep 29, 2020 at 9:19 AM Andrey Rahmatullin wrote: > > > > > > On Tue, Sep 29, 2020 at 09:15:41AM -0400, Tong Sun wrote: > > > > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and > > > > > > I see > > > > > > > > > > > > $ grep -B10 libgit2-dev debian/control > > > > > > Build-Depends: debhelper (>= 11), > > > > > > dh-cargo (>= 18), > > > > > > cargo:native , > > > > > > rustc:native , > > > > > > libstd-rust-dev , > > > > > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > > > > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > > > > > librust-libc-0.2+default-dev , > > > > > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > > > > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > > > > > libgit2-dev > > > > > What do you mean by this? > > > > > > > > Same train of thoughts as above. Is there anything special that you > > > > picked this particular section out? > > > I didn't? > > > I just don't know how is this related to everything else. > > > > Oh, I was just using the same command as previously, and want to be > > true to the fact and don't want to edit/remove anything, which shows > > that this time libgit2-dev showed up twice. > Where is it shown twice? In OP, which you didn't include. That is why I was wondering if there is anything special that you picked this particular section out, because this is not the part I had the question, but only remained as a reference.
Re: gfortran-10 issue in raster3d
On Tuesday, 29 September 2020 07:38:18 PDT Andreas Tille wrote: > Hi, > > I tried to update the raster3d package in Debian[1] but it fails to > build with: > > gfortran -g -w -O2 -Wno-tabs -ffixed-line-length-132 -c -o render.o render.f > render.f:1078:13: Yes. To build with gfortran version>10.0 requires compiler flag -std=legacy inverted sense of flag -Wtabs (what were they thinking of?!) modified octal constants in source I have put an updated package on the upstream distribution site. distribution: http://skuld.bmsc.washington.edu/raster3d/raster3d.html updated tarball: http://skuld.bmsc.washington.edu/raster3d/Raster3D_3.0-7.tar.gz cheers, Ethan > > 1078 | IERR = LOCAL(1, NAX, NAY, OTMODE, QUALITY) > | 1 > Error: More actual than formal arguments in procedure call at (1) > render.f:1079:22: > > 1077 | IERR = LOCAL(5, IBKGND(1), IBKGND(2), IBKGND(3)) > | 2 > 1078 | IERR = LOCAL(1, NAX, NAY, OTMODE, QUALITY) > 1079 | IERR = LOCAL(4, TITLE) > | 1 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (CHARACTER(132)/INTEGER(4)). > render.f:4402:22: > > 1077 | IERR = LOCAL(5, IBKGND(1), IBKGND(2), IBKGND(3)) > | 2 > .. > 4402 | IERR = LOCAL(2, OUTBUF(K+1,1), OUTBUF(K+1,2), OUTBUF(K+1,3), > | 1 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (INTEGER(2)/INTEGER(4)). > render.f:4430:13: > > 4430 | IERR = LOCAL(3) > | 1 > Error: Missing actual argument for argument '_formal_4' at (1) > make[2]: *** [: render.o] Error 1 > > > Any help would be welcome. > > Kind regards > > Andreas. > > [1] https://salsa.debian.org/med-team/raster3d > > -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg MS 357742, University of Washington, Seattle 98195-7742
Bug#971388: RFS: golang-github-dkolbly-wl/0.0~git20180220.b06f57e-1 [ITP] -- Golang wayland protocol implementation. (library)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-dkolbly-wl": * Package name: golang-github-dkolbly-wl Version : 0.0~git20180220.b06f57e-1 Upstream Author : https://github.com/dkolbly/wl/issues * URL : https://github.com/dkolbly/wl * License : BSD-2-clause * Vcs : https://salsa.debian.org/go-team/packages/golang-github-dkolbly-wl Section : devel It builds those binary packages: golang-github-dkolbly-wl-dev - Golang wayland protocol implementation. (library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-dkolbly-wl/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-dkolbly-wl/golang-github-dkolbly-wl_0.0~git20180220.b06f57e-1.dsc Changes for the initial release: golang-github-dkolbly-wl (0.0~git20180220.b06f57e-1) unstable; urgency=medium . * Initial release (Closes: #971042) Regards, -- Arun Kumar Pariyar signature.asc Description: OpenPGP digital signature
Bug#971386: RFS: golang-github-kelvins-sunrisesunset/1.0-1 [ITP] -- Go package that provides the sunrise and sunset equation.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "golang-github-kelvins-sunrisesunset": * Package name: golang-github-kelvins-sunrisesunset Version : 1.0-1 Upstream Author : Kelvin S. do Prado * URL : https://github.com/kelvins/sunrisesunset * License : Expat * Vcs : https://salsa.debian.org/go-team/packages/golang-github-kelvins-sunrisesunset Section : devel It builds those binary packages: golang-github-kelvins-sunrisesunset-dev - Go package that provides the sunrise and sunset equation. (library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-kelvins-sunrisesunset/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-kelvins-sunrisesunset/golang-github-kelvins-sunrisesunset_1.0-1.dsc Changes for the initial release: golang-github-kelvins-sunrisesunset (1.0-1) unstable; urgency=medium . * Initial release (Closes: #971046) Regards, -- Arun Kumar Pariyar signature.asc Description: OpenPGP digital signature
Bug#960831: about RFS: yiyantang
On Tue, Sep 29, 2020 at 10:04:16AM +0800, xiao sheng wen (肖盛文) wrote: > Hi, Paul,Tobias, > > Thanks for your review. > > I had uploaded the new package, please help to review again. > > About the upstream: > > I can't find any forks that could be new upstream on Internet. So, congrats for becoming de-facto* upstream then… ;-) (* due to maintaining a dead-upstream package) > About the "not using autoreconf": > > If use autoreconf, the build will failed: > > automake: warning: autoconf input should be named 'configure.ac', not > 'configure.in' > autoreconf: automake failed with exit status: 1 > dh_autoreconf: error: autoreconf -f -i returned exit code 1 Yes, I see*. But I fear that needs to be debugged and eventually be fixed or it will fly right into your face, at some point of time**… At the very least, config.guess and config.sub needs updating frequently. (See /usr/share/doc/autotools-dev/README.Debian.gz) > The source code is old, it use configure.in. (* The reason for the failure seems to be in configure.in:59; but I did not try anything except commenting out that line; autoreconf suceeds then but configure fails later.) (**I'm not saying you need to fix that right away; maybe you are lucky and it never explodes…) fix-typo-patch -> Please s/type/typo also in the dep3 headers. [nitpick] d/copyright: - You need to have the complete GPL boiler plate in the License text. Note, if you license debian/* GPL-2*+* you need to have an extra section for the different license. (GPL-2 != GPL-2+) - Please also mention the previous maintainers in the debian/* section. d/rules [nitpick] - Please wrap the long lines. Please fix d/copyright and possibly also the nitpicks and I will take a look again. -- tobi
gfortran-10 issue in raster3d
Hi, I tried to update the raster3d package in Debian[1] but it fails to build with: gfortran -g -w -O2 -Wno-tabs -ffixed-line-length-132 -c -o render.o render.f render.f:1078:13: 1078 | IERR = LOCAL(1, NAX, NAY, OTMODE, QUALITY) | 1 Error: More actual than formal arguments in procedure call at (1) render.f:1079:22: 1077 | IERR = LOCAL(5, IBKGND(1), IBKGND(2), IBKGND(3)) | 2 1078 | IERR = LOCAL(1, NAX, NAY, OTMODE, QUALITY) 1079 | IERR = LOCAL(4, TITLE) | 1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (CHARACTER(132)/INTEGER(4)). render.f:4402:22: 1077 | IERR = LOCAL(5, IBKGND(1), IBKGND(2), IBKGND(3)) | 2 .. 4402 | IERR = LOCAL(2, OUTBUF(K+1,1), OUTBUF(K+1,2), OUTBUF(K+1,3), | 1 Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(2)/INTEGER(4)). render.f:4430:13: 4430 | IERR = LOCAL(3) | 1 Error: Missing actual argument for argument '_formal_4' at (1) make[2]: *** [: render.o] Error 1 Any help would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/raster3d -- http://fam-tille.de
Re: Verify the library transition
On Tue, Sep 29, 2020 at 09:41:58AM -0400, Tong Sun wrote: > On Tue, Sep 29, 2020 at 9:19 AM Andrey Rahmatullin wrote: > > > > On Tue, Sep 29, 2020 at 09:15:41AM -0400, Tong Sun wrote: > > > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I > > > > > see > > > > > > > > > > $ grep -B10 libgit2-dev debian/control > > > > > Build-Depends: debhelper (>= 11), > > > > > dh-cargo (>= 18), > > > > > cargo:native , > > > > > rustc:native , > > > > > libstd-rust-dev , > > > > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > > > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > > > > librust-libc-0.2+default-dev , > > > > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > > > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > > > > libgit2-dev > > > > What do you mean by this? > > > > > > Same train of thoughts as above. Is there anything special that you > > > picked this particular section out? > > I didn't? > > I just don't know how is this related to everything else. > > Oh, I was just using the same command as previously, and want to be > true to the fact and don't want to edit/remove anything, which shows > that this time libgit2-dev showed up twice. Where is it shown twice? -- WBR, wRAR signature.asc Description: PGP signature
Re: Verify the library transition
On Tue, Sep 29, 2020 at 9:19 AM Andrey Rahmatullin wrote: > > On Tue, Sep 29, 2020 at 09:15:41AM -0400, Tong Sun wrote: > > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see > > > > > > > > $ grep -B10 libgit2-dev debian/control > > > > Build-Depends: debhelper (>= 11), > > > > dh-cargo (>= 18), > > > > cargo:native , > > > > rustc:native , > > > > libstd-rust-dev , > > > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > > > librust-libc-0.2+default-dev , > > > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > > > libgit2-dev > > > What do you mean by this? > > > > Same train of thoughts as above. Is there anything special that you > > picked this particular section out? > I didn't? > I just don't know how is this related to everything else. Oh, I was just using the same command as previously, and want to be true to the fact and don't want to edit/remove anything, which shows that this time libgit2-dev showed up twice. Thanks for your help Andrey, I'll get back for the rest to you tonight...
Re: Verify the library transition
On Tue, Sep 29, 2020 at 09:15:41AM -0400, Tong Sun wrote: > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see > > > > > > $ grep -B10 libgit2-dev debian/control > > > Build-Depends: debhelper (>= 11), > > > dh-cargo (>= 18), > > > cargo:native , > > > rustc:native , > > > libstd-rust-dev , > > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > > librust-libc-0.2+default-dev , > > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > > libgit2-dev > > What do you mean by this? > > Same train of thoughts as above. Is there anything special that you > picked this particular section out? I didn't? I just don't know how is this related to everything else. -- WBR, wRAR signature.asc Description: PGP signature
Re: Verify the library transition
Thanks Andrey. On Tue, Sep 29, 2020 at 8:39 AM Andrey Rahmatullin wrote: > > On Tue, Sep 29, 2020 at 08:30:33AM -0400, Tong Sun wrote: > > So `libgit2-dev` only shows up once in calligra's debian/control file. > You need to check actual dependencies of binary packages (e.g. by looking at > debs with dpkg-deb -f), not your debian/control. > And libgit2-dev is a development package, binaries will depend on the > package that contains the library itself. > > > I.e., none of the packages actually depends on it, which is kind of > > what I found. Is it true? > Yes, packages that link against a lib shouldn't depend on a -dev. No, you > cannot see binary package deps in debian/control. > > > Can I safely say that all calligra packages are fine with libgit2-dev's new > > v1.0.0? > No. > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see > > > > $ grep -B10 libgit2-dev debian/control > > Build-Depends: debhelper (>= 11), > > dh-cargo (>= 18), > > cargo:native , > > rustc:native , > > libstd-rust-dev , > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > librust-libc-0.2+default-dev , > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > libgit2-dev > What do you mean by this? Same train of thoughts as above. Is there anything special that you picked this particular section out?
Re: Verify the library transition
On Tue, Sep 29, 2020 at 08:30:33AM -0400, Tong Sun wrote: > So `libgit2-dev` only shows up once in calligra's debian/control file. You need to check actual dependencies of binary packages (e.g. by looking at debs with dpkg-deb -f), not your debian/control. And libgit2-dev is a development package, binaries will depend on the package that contains the library itself. > I.e., none of the packages actually depends on it, which is kind of > what I found. Is it true? Yes, packages that link against a lib shouldn't depend on a -dev. No, you cannot see binary package deps in debian/control. > Can I safely say that all calligra packages are fine with libgit2-dev's new > v1.0.0? No. > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see > > $ grep -B10 libgit2-dev debian/control > Build-Depends: debhelper (>= 11), > dh-cargo (>= 18), > cargo:native , > rustc:native , > libstd-rust-dev , > librust-cc-1+default-dev (>= 1.0.42-~~) , > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > librust-libc-0.2+default-dev , > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > libgit2-dev What do you mean by this? -- WBR, wRAR signature.asc Description: PGP signature
Re: Verify the library transition
On Tue, Sep 29, 2020 at 3:14 AM Andrey Rahmatullin wrote:
>
> On Mon, Sep 28, 2020 at 09:55:17PM -0400, Tong Sun wrote:
> > Of all the above 46 newly built binary-only packages, how can I tell
> > which .so from them will link to libgit2-dev, and whether the
> > libgit2-dev version linked is truly v1.0.0? Note this is more a
> > generic question and not specific for calligra.
> Check the package dependencies.
OK.
$ grep -B20 libgit2-dev debian/control
Source: calligra
Section: kde
Priority: optional
Maintainer: Debian Qt/KDE Maintainers
Uploaders: Adrien Grellier ,
Raúl Sánchez Siles ,
Maximiliano Curia
Build-Depends: cmake,
debhelper-compat (= 12),
extra-cmake-modules (>= 5.19.0),
gettext,
kross-dev (>= 5.7.0),
libboost-dev,
libboost-system-dev,
libeigen3-dev,
libetonyek-dev,
libfontconfig-dev,
libfreetype-dev,
libgit2-dev,
So `libgit2-dev` only shows up once in calligra's debian/control file.
I.e., none of the packages actually depends on it, which is kind of
what I found. Is it true? Can I safely say that all calligra packages
are fine with libgit2-dev's new v1.0.0?
Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see
$ grep -B10 libgit2-dev debian/control
Build-Depends: debhelper (>= 11),
dh-cargo (>= 18),
cargo:native ,
rustc:native ,
libstd-rust-dev ,
librust-cc-1+default-dev (>= 1.0.42-~~) ,
librust-cc-1+parallel-dev (>= 1.0.42-~~) ,
librust-libc-0.2+default-dev ,
librust-libz-sys-1+default-dev (>= 1.0.22-~~) ,
librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) ,
libgit2-dev
--
Package: librust-libgit2-sys-dev
Architecture: any
Multi-Arch: same
Depends:
${misc:Depends},
librust-cc-1+default-dev (>= 1.0.42-~~),
librust-cc-1+parallel-dev (>= 1.0.42-~~),
librust-libc-0.2+default-dev,
librust-libz-sys-1+default-dev (>= 1.0.22-~~),
librust-pkg-config-0.3+default-dev (>= 0.3.7-~~),
libgit2-dev
I.e., the package that actually depends on libgit2-dev is
librust-libgit2-sys-dev. However, when I check the build results under
.../libgit2-dev/dep/rust-libgit2-sys-0.10.0/debian/librust-libgit2-sys-dev:
$ find usr/
usr/
usr/share
usr/share/cargo
usr/share/cargo/registry
usr/share/cargo/registry/libgit2-sys-0.10.0
usr/share/cargo/registry/libgit2-sys-0.10.0/Cargo.toml
usr/share/cargo/registry/libgit2-sys-0.10.0/LICENSE-MIT
usr/share/cargo/registry/libgit2-sys-0.10.0/lib.rs
usr/share/cargo/registry/libgit2-sys-0.10.0/build.rs
usr/share/cargo/registry/libgit2-sys-0.10.0/.cargo_vcs_info.json
usr/share/cargo/registry/libgit2-sys-0.10.0/debian
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches/abi-compat-0.28.3.patch
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches/series
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches/no-special-snowflake-env.patch
usr/share/cargo/registry/libgit2-sys-0.10.0/.cargo-checksum.json
usr/share/cargo/registry/libgit2-sys-0.10.0/LICENSE-APACHE
usr/share/doc
usr/share/doc/librust-libgit2-sys-dev
usr/share/doc/librust-libgit2-sys-dev/copyright
usr/share/doc/librust-libgit2-sys-dev/changelog.Debian.gz
I don't see any library built. So can I also safely say that it is
fine with libgit2-dev's new v1.0.0 as well?
thx
Bug#971067: RFS: libexif-gtk/0.5.0-1
On 2020-09-27 Hugh McMaster wrote:
[...]
> I am looking for a sponsor to upload the package "libexif-gtk" to NEW,
> as switching to GTK 3 caused the main package to be renamed.
> * Package name: libexif-gtk
[...]
> The source builds the following binary packages:
> libexif-gtk-dev - Library providing GTK+ widgets to display/edit
> EXIF tags (development files)
> libexif-gtk5 - Library providing GTK+ widgets to display/edit EXIF
> tags (transitional package)
> libexif-gtk3-5 - Library providing GTK+ widgets to display/edit EXIF tags
[...]
Hello Hugh,
I have just taken a quick look:
[nitpick] Explicit b-dep on autopoint is superfluous, debhelper pulls it
in for dh_autoreconf.
The transitional package makes no sense, it actually causes breakage.
Packages depend on libexif-gtk5 because they need a library with soname
libexif-gtk.so.5. The dummy package makes libexif-gtk5 0.5.0-1 +
libexif-gtk3-5 fulfill this dependency without providing
libexif-gtk.so.5. Any package depending on libexif-gtk5 will need to be
rebuilt against libexif-gtk-dev 0.5 and will then depend on
libexif-gtk3-5.
Also libexif-gtk5 0.4 and libexif-gtk3-5 should be co-installable (no
breaks/replaces - policy 8.1, worth reading in whole), afaict this
should be easily possible once the gettext message catalogues names are
versioned. I /think/ (untested!) this should do the trick:
--- libexif-gtk-0.5.0.orig/configure.ac
+++ libexif-gtk-0.5.0/configure.ac
@@ -47,7 +47,7 @@ dnl GP_CONFIG_MSG([Features])
# ---
ALL_LINGUAS="de es fr pl ru"
AM_PO_SUBDIRS
-GP_GETTEXT_HACK([${PACKAGE}-${LIBEXIF_GTK_CURRENT}],
+GP_GETTEXT_HACK([${PACKAGE}3-${LIBEXIF_GTK_CURRENT}],
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Re: Verify the library transition
On Mon, Sep 28, 2020 at 09:55:17PM -0400, Tong Sun wrote: > Of all the above 46 newly built binary-only packages, how can I tell > which .so from them will link to libgit2-dev, and whether the > libgit2-dev version linked is truly v1.0.0? Note this is more a > generic question and not specific for calligra. Check the package dependencies. -- WBR, wRAR signature.asc Description: PGP signature
Bug#969789: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "elfio": * Package name: elfio Version : 3.7-1 Upstream Author : Serge Lamikhov-Center * URL : http://serge1.github.io/ELFIO * License : Expat * Vcs : https://github.com/serge1/ELFIO Section : devel It builds those binary packages: elfio - C++ library for reading and generating ELF files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elfio/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc Changes for the initial release: elfio (3.7-1) unstable; urgency=medium
