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
