userspace tools
libvpb1 - Voicetronix telephony hardware userspace interface library
libvpb-dev - Voicetronix telephony hardware userspace library development
files
libvpb-doc - Voicetronix telephony interface library documentation
libvpb-dbg - debugging symbols for libvpb and vpb-utils
To
extension does not seem to be in deb-symbols(5).
>
> See the deb-src-symbols(5) manual page, I think you want this:
>
> (arch=!arm64|c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
> gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5
On Sat, 2022-08-13 at 11:31 +0200, Marc Haber wrote:
> I think this is worth doing only if the number of your reverse depends
> is well in the two-digit range or above that. That doesn't apply (yet)
> to gensio, so I'm likely to remove the symbols file from my package
>
On Sat, 2022-08-13 at 22:19 +0200, Marc Haber wrote:
> dpkg-gensymbols does not seem to be willing to grok the second line
> ("gensio_log_levels, not a valid version").
>
> Also, the arch extension does not seem to be in deb-symbols(5).
See the deb-src-symbols(5) manual
gt;
> (arch=!i386
> !x32)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
> gensios::gensio_log_levels, char const*, __va_list_tag*)@Base"
Just in case I want to use this opportunity to get a feeling for symbols
files, can I also specify architectures for which a l
On Sat, Aug 13, 2022 at 11:19:24AM +0800, Paul Wise wrote:
> On Fri, 2022-08-12 at 12:06 +0200, Marc Haber wrote:
>
> > what's the benefit in having a symbols file?
>
> It means that packages depending on a library can relax their version
> dependencies on that library
On Fri, 2022-08-12 at 12:06 +0200, Marc Haber wrote:
> what's the benefit in having a symbols file?
It means that packages depending on a library can relax their version
dependencies on that library to the oldest version that supports all
the symbols they use. Until the symbols mecha
Hej Marc,
the following page might help you:
https://qt-kde-team.pages.debian.net/symbolfiles.html
In short: The Qt/KDE team has a couple of helpers that simplify handling
symbolfiles significantly. The page explains when you can use them and
how you can use them.
The helpers also take care of
i386
> !x32)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
> gensios::gensio_log_levels, char const*, __va_list_tag*)@Base"
But isn't that as bad as maintaining a package.symbols.$ARCH for every
arch?
And what's the benefit in having a symbols file? Pe
On Fri, 2022-08-12 at 07:00 +0200, Tobias Frost wrote:
> ${shlibs:Depends}
I mean for the library, what do you set debian/$package.shlibs to?
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
On Fri, Aug 12, 2022 at 09:34:42AM +0800, Paul Wise wrote:
> On Thu, 2022-08-11 at 16:10 +0200, Tobias Frost wrote:
>
> > I tried them on a few occasions only to drop them a few uploads later, as
> > they add a lot of maintainance burden. They will frequently break, as some
> > other package or to
Hi Marc,
Em qui., 11 de ago. de 2022 às 09:22, Marc Haber
escreveu:
>
> Hi,
>
> my package gensio, which generates a library package, has recently
> thrown a few lintian warnings regarding missing symbols files. I read
> the wiki page and the manual page of dpkg-gensymb
On Thu, 2022-08-11 at 16:10 +0200, Tobias Frost wrote:
> I tried them on a few occasions only to drop them a few uploads later, as
> they add a lot of maintainance burden. They will frequently break, as some
> other package or toolchain might have influences, are
> architecture dependent and once
On Thu, Aug 11, 2022 at 02:22:25PM +0200, Marc Haber wrote:
> Hi,
>
> my package gensio, which generates a library package, has recently
> thrown a few lintian warnings regarding missing symbols files. I read
> the wiki page and the manual page of dpkg-gensymbols and had
&g
Hi,
my package gensio, which generates a library package, has recently
thrown a few lintian warnings regarding missing symbols files. I read
the wiki page and the manual page of dpkg-gensymbols and had
dpkg-gensymbols generate a debian/libgensio0.symbols file, added the
Build-Depends-Package line
* License : CC0
* Vcs : https://salsa.debian.org/debian/braillefont
Section : text
It builds those binary packages:
braillefont - Prints a bitmapped version of a text using Unicode Braille
symbols
To access further information about this package, please visit the foll
Hi Andreas,
Andreas Tille, on 2020-10-17 21:52:24 +0200:
> /usr/bin/ld:
> paw/cdf/shared/mlpdef.o:/build/paw-2.14.04.dfsg.2/build/pawlib/paw/cdf/mlpdef.c:155:
> multiple definition of `klnkaddr';
> paw/cdf/shared/pawcdf.o:/build/paw-2.14.04.dfsg.2/build/pawlib/paw/cdf/pawcdf.c:155:
> first def
Hi Andrius
On Thu, Oct 15, 2020 at 03:34:15PM +0300, Andrius Merkys wrote:
>
> FFLAGS += -fallow-argument-mismatch
Thanks a lot for the helpful hint which enabled me to do one
step forward[1]. Unfortunately there are further errors:
...
/usr/bin/ld:
paw/cdf/shared/mlpdef.o:/build/paw-2.14.04.
On Fri, Dec 06, 2019 at 06:24:49PM +0100, Alf Gaida wrote:
> Am 06.12.2019 um 17:37 schrieb Ole Streicher:
> > How should one handle this?
> >
> > Best regards
> >
> > Ole
> >
> Arch dependend symbols are a pain in the ... :D
However, it can be
Andrey Rahmatullin writes:
> On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote:
>> for the "casacore" package (written in C++), we wanted to introduce
>> symbols files for the shared libraries it produces. However, this
>> somehow does not work
Am 06.12.2019 um 17:37 schrieb Ole Streicher:
How should one handle this?
Best regards
Ole
Arch dependend symbols are a pain in the ... :D
there are some approaches to handle it - one could have a look into the
KDE packaging tools and packaging how the KDE team handle this. I use a
On Fri, Dec 06, 2019 at 05:37:25PM +0100, Ole Streicher wrote:
> Hi,
>
> for the "casacore" package (written in C++), we wanted to introduce
> symbols files for the shared libraries it produces. However, this
> somehow does not work, as they seem to depend on the ar
Hi,
for the "casacore" package (written in C++), we wanted to introduce
symbols files for the shared libraries it produces. However, this
somehow does not work, as they seem to depend on the architecture and/or
the C++ compiler version:
https://buildd.debian.org/status/logs.php?pkg=ca
On Wed, Sep 12, 2018 at 10:17:13AM +0500, Andrey Rahmatullin wrote:
> On Wed, Sep 12, 2018 at 04:38:05AM +, Mo Zhou wrote:
> > I'm confused about which symbol would be eventually loaded when
> > different shared objects provides different implementation for
> > the same function signature, e.g.
On Wed, Sep 12, 2018 at 04:38:05AM +, Mo Zhou wrote:
> I'm confused about which symbol would be eventually loaded when
> different shared objects provides different implementation for
> the same function signature, e.g. (glibc)malloc and (jemalloc)malloc .
Loading order usually. You can consult
Hi mentors,
I'm confused about which symbol would be eventually loaded when
different shared objects provides different implementation for
the same function signature, e.g. (glibc)malloc and (jemalloc)malloc .
Debian's jemalloc package doesn't mangle the function names, i.e.
jemalloc's malloc imp
Hi Andreas,
On 05/23/2018 12:11 PM, Andreas Tille wrote:
> Hi,
>
> I've created a symbols file for libseqlib version 1.1.1+dfsg since I
> suspected an ABI change by upstream. A test build with this symbols
> file went fine without lintian errors. I upgraded to libseqlib v
Hi,
I've created a symbols file for libseqlib version 1.1.1+dfsg since I
suspected an ABI change by upstream. A test build with this symbols
file went fine without lintian errors. I upgraded to libseqlib version
1.1.2 which in fact had an ABI change[2]. I have upgraded the symbols
Mattia Rizzolo wrote:
> On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> > Andreas Tille wrote:
> > > What's the correct way to fix the symbols file to work with both
> > > versions of gcc?
> >
> > Don't use symbols files f
On Sat, May 5, 2018 at 7:12 AM, Mattia Rizzolo wrote:
> ABI breaks are awful to handle after they land in unstable, catching one
> before can save the maintainer, release team and all the rdeps *a lot*
> of otherwise wasted time and headaches.
We really do need a service doing full ABI tracking u
On Sat, May 05, 2018 at 12:45:08AM +0200, Svante Signell wrote:
> But why log symbols at all? It
> seems to be very much not needed. If so tell me why it is!
Mainly I see two reasons:
1. being able to use properly versioned dependencies on the library
2. have a safety net against what ar
On Fri, 2018-05-04 at 23:16 +0200, Mattia Rizzolo wrote:
> Yavor,
>
> On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> > Andreas Tille wrote:
> > > What's the correct way to fix the symbols file to work with both
> > > versions of gcc?
&g
On Fri, May 04, 2018 at 02:52:30PM +0200, Andreas Tille wrote:
> there are several bugs filed against packages of the Debian Med
> team.
Well, it's not really only about Debian Med...
> What's the correct way to fix the symbols file to work
> with both versions of gcc?
As
Yavor,
On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> Andreas Tille wrote:
> > What's the correct way to fix the symbols file to work with both
> > versions of gcc?
>
> Don't use symbols files for C++ libraries?
Please do not advocate nor recomm
Andreas Tille writes:
> Well, it took a *long* time before I've undergone the process from
> ignoring symbols files to finally providing some in cases where there
> are good reasons to use them. Shortly after I now get adise to not
> use them. I'm not sure whether this is
On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> Andreas Tille wrote:
> > What's the correct way to fix the symbols file to work with both
> > versions of gcc?
>
> Don't use symbols files for C++ libraries?
Well, it took a *long* time before
On Fri, 04 May 2018 15:52:30 +0300,
Andreas Tille wrote:
> What's the correct way to fix the symbols file to work with both
> versions of gcc?
Don't use symbols files for C++ libraries?
Hi,
there are several bugs filed against packages of the Debian Med
team. What's the correct way to fix the symbols file to work
with both versions of gcc?
Kind regards
Andreas.
On Fri, May 04, 2018 at 12:22:23PM +, Matthias Klose wrote:
> Package: src:libquazip
> Versi
On 04/06/2018 05:48 PM, Andreas Tille wrote:
> Hi Bas,
>
> On Fri, Apr 06, 2018 at 02:18:03PM +0200, Sebastiaan Couwenberg wrote:
>> On 04/06/2018 02:08 PM, Andreas Tille wrote:
>>> after adding a symbols file to libbpp-core all other architectures are
>>> fail
Hi Bas,
On Fri, Apr 06, 2018 at 02:18:03PM +0200, Sebastiaan Couwenberg wrote:
> On 04/06/2018 02:08 PM, Andreas Tille wrote:
> > after adding a symbols file to libbpp-core all other architectures are
> > failing due to different symbols (see below for ppc64el[1]) but others
>
On 04/06/2018 02:08 PM, Andreas Tille wrote:
> after adding a symbols file to libbpp-core all other architectures are
> failing due to different symbols (see below for ppc64el[1]) but others
> are failing as well. What is the correct way to fix this?
Use (arch=ppc64el) tags for the sy
Hi,
after adding a symbols file to libbpp-core all other architectures are
failing due to different symbols (see below for ppc64el[1]) but others
are failing as well. What is the correct way to fix this?
Kind regards
Andreas.
On Fri, Apr 06, 2018 at 11:04:02AM +0200, Julien Yann Dutheil
Your message dated Sat, 3 Mar 2018 19:58:26 +0100
with message-id <20180303185826.nuo6vcxxwc7cc...@angband.pl>
and subject line Re: Bug#891643: RFS: inkscape-open-symbols/1.2.1-1
has caused the Debian Bug report #891643,
regarding RFS: inkscape-open-symbols/1.2.1-1
to be marked as done.
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for the latest version of my package
"inkscape-open-symbols".
Download with dget:
dget -x
https://mentors.debian.net/debian/pool/main/i/inkscape-open-symbols/inkscape-open-symbols_1.2.1
Your message dated Sat, 28 Jan 2017 19:22:02 +0100
with message-id <20170128182202.i2xshyop7yhni...@angband.pl>
and subject line Re: Bug#852838: RFS: inkscape-open-symbols/1.1-2
has caused the Debian Bug report #852838,
regarding RFS: inkscape-open-symbols/1.1-2
to be marked as done.
This
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package "inkscape-open-symbols".
inkscape-open-symbols - Open source SVG symbol sets that can be used as
Inkscape symbols
Package: inkscape-open-symbols
Version: 1.1-2
Upstream Auth
Your message dated Fri, 13 Jan 2017 15:11:26 +0100
with message-id <20170113141126.lt3kygmvq7bz4...@angband.pl>
and subject line Re: Bug#850821: RFS: inkscape-open-symbols/1.0-1
has caused the Debian Bug report #850821,
regarding RFS: inkscape-open-symbols/1.0-1 [ITP]
to be marked as done.
here:
>>
>>dget -x
>> https://mentors.debian.net/debian/pool/main/i/inkscape-open-symbols/inkscape-open-symbols_1.1-1.dsc
>
> I'm afraid that URL is 404-compliant.
> I can't find it on mentors.debian.net either.
>
> Meow!
It's seems to work now. Maybe mentors took time to synchronize?
signature.asc
Description: PGP signature
On Fri, Jan 13, 2017 at 01:14:20PM +0100, Félix Sipma wrote:
> Upstream updated the license to Expat, and I updated the license of debian/ to
> GPL-3+
>
> Please find the updated package there:
>
> dget -x
> https://mentors.debian.net/debian/pool/main/i/inkscape-open-
Control: tag -1 -moreinfo
Upstream updated the license to Expat, and I updated the license of debian/ to
GPL-3+
Please find the updated package there:
dget -x
https://mentors.debian.net/debian/pool/main/i/inkscape-open-symbols/inkscape-open-symbols_1.1-1.dsc
On 2017-01-11 11:27+0100
x27;re mixing GPL-2 and GPL-3+. I believe this is not a
>>> problem between symbol sets -- there's mere aggregation without derivation
>>> or linking, but this can't be said for packaging.
>>
>> There's a discussion about the licensing there:
>
gt; > problem between symbol sets -- there's mere aggregation without derivation
> > or linking, but this can't be said for packaging.
>
> There's a discussion about the licensing there:
> https://github.com/Xaviju/inkscape-open-symbols/issues/61
>
> I'm not
vation
> or linking, but this can't be said for packaging.
There's a discussion about the licensing there:
https://github.com/Xaviju/inkscape-open-symbols/issues/61
I'm not sure about how inkscape-open-symbols could be licensed (for now it's
GPL-2, so it's problematic, isn
On 2017-01-11 11:27+0100, Adam Borowski wrote:
> Control: tag -1 +moreinfo
>
> On Tue, Jan 10, 2017 at 02:38:00PM +0100, Félix Sipma wrote:
>> I am looking for a sponsor for my package "inkscape-open-symbols".
>> inkscape-open-symbols - Open source SVG symbol sets t
Control: tag -1 +moreinfo
On Tue, Jan 10, 2017 at 02:38:00PM +0100, Félix Sipma wrote:
> I am looking for a sponsor for my package "inkscape-open-symbols".
> inkscape-open-symbols - Open source SVG symbol sets that can be used as
> Inkscape symbols
>
> Package: inksca
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package "inkscape-open-symbols".
inkscape-open-symbols - Open source SVG symbol sets that can be used as
Inkscape symbols
Package: inkscape-open-symbols
Version: 1.0-1
Upstream Auth
Hi lumin,
2016-12-02 14:36 GMT-02:00 lumin :
> Hi mentors,
>
> I need advise on the way maintaining symbols control file when
> the mangled C++ symbols are unstable.
>
> I'm maintaining a package named "Caffe". I migrated the same
> source from experimental
On 02/12/16 18:11, Jérémy Lal wrote:
2016-12-02 18:08 GMT+01:00 Ghislain Vaillant :
On 02/12/16 16:36, lumin wrote:
Hi mentors,
I need advise on the way maintaining symbols control file when
the mangled C++ symbols are unstable.
I'm maintaining a package named "Caffe". I mi
Hi,
>I need advise on the way maintaining symbols control file when
>the mangled C++ symbols are unstable.
maintaining symbols on C++ projects is a nightmare.
and do subsequent uploads is done also by qt* folks
(see e.g. qtbase uploads).
You can consider however some things, e.g. m
2016-12-02 18:08 GMT+01:00 Ghislain Vaillant :
> On 02/12/16 16:36, lumin wrote:
>>
>> Hi mentors,
>>
>> I need advise on the way maintaining symbols control file when
>> the mangled C++ symbols are unstable.
>>
>> I'm maintaining a package
On 02/12/16 16:36, lumin wrote:
Hi mentors,
I need advise on the way maintaining symbols control file when
the mangled C++ symbols are unstable.
I'm maintaining a package named "Caffe". I migrated the same
source from experimental to unstable, and it FTBFS'ed as you
se
Hi mentors,
I need advise on the way maintaining symbols control file when
the mangled C++ symbols are unstable.
I'm maintaining a package named "Caffe". I migrated the same
source from experimental to unstable, and it FTBFS'ed as you
see at [0], due to the mangled C++ symb
it
>comes to ABI-compatibility.)
yep, indeed!
>Yes, that's more or less what I would have done. But I suspect
>that the new symbols were added in 1.1, not 1.1.2, so I'd maybe
>use that as the minimum version. (After checking the upstream
>tarball.) Not terribly important, bec
nlikely to screw up when it
comes to ABI-compatibility.)
> so, I would have changed the symbols file in this way:
> libu2f-host.so.0 libu2f-host0 #MINVER#
> U2F_HOST_0.0@U2F_HOST_0.0 0.0
> + U2F_HOST_1.1@U2F_HOST_1.1 1.1.2
> u2fh_authenticate@U2F_HOST_0.0 0.0
> +
hat is, the original symbols file was
erroneous.
what does this mean? do reverse-dependencies needs a rebuild then?
In the second case, some rev-deps might need to be rebuilt to correct
their Depends.
--
Jakub Wilk
Hi Christian, thanks for the help and answer!
I admit it looked wrong to me too, but your explanation is perfect!
so, I would have changed the symbols file in this way:
libu2f-host.so.0 libu2f-host0 #MINVER#
U2F_HOST_0.0@U2F_HOST_0.0 0.0
+ U2F_HOST_1.1@U2F_HOST_1.1 1.1.2
u2fh_authenticate
On 07/06/2016 10:36 AM, Gianfranco Costamagna wrote:
> all the symbols have been updated:
> e.g.
>
> [snip]
>
> - u2fh_check_version@U2F_HOST_0.0 0.0
>
> + u2fh_check_version@U2F_HOST_0.0 1.0
That's a change in the minimum version of the symbol, but not the
symbol
to -mentors mail list)
all the symbols have been updated:
e.g.
[snip]
- u2fh_check_version@U2F_HOST_0.0 0.0
+ u2fh_check_version@U2F_HOST_0.0 1.0
[snip]
what does this mean? do reverse-dependencies needs a rebuild then?
reverse-depends -b libu2f-host-dev
Reverse-Build-Depends
=
* Jörg Frings-Fürst , 2016-04-02, 10:41:
The result looks like that all builds use an other symbols
file as base, because already the second line differs from
the original.
Why?
Looks like a bug in dpkg-gensymbols(1). You might want to file the bug
in the BTS.
This circumstance also
Hi,
On Sat, 2016-04-02 at 10:41 +0200, Jörg Frings-Fürst wrote:
> I have some questions about the handling of symbols files at Debian.
>
> The quotes based on the package bitz-server[1].
>
> My symbols file are[2]:
>
> [quote]
> libicap.so.1 libicap1 #MINVER#
>
Hello,
I have some questions about the handling of symbols files at Debian.
The quotes based on the package bitz-server[1].
My symbols file are[2]:
[quote]
libicap.so.1 libicap1 #MINVER#
(c++)"icap::RequestHeader::read_header(std::__cxx11::basic_string, std::allocator > const&)
* Eriberto , 2016-01-06, 22:36:
export PVER=$(shell dpkg-parsechangelog --show-field version | cut
-d"-" -f1)
%:
dh $@
override_dh_makeshlibs:
dh_makeshlibs -- -v$(PVER)
No, please don't do this.
IMO, it is right and works fine. What is the specific problem?
It doesn't fi
Hi,
>Updated package is at http://mentors.debian.net/package/kpmcore
am I wrong or I failed to see an RFS bug?
or do you already have a sponsor?
sorry but without a bug is difficult to keep track of packages needing a sponsor
cheers,
G.
On 07/01/2016 01:55, Jonathan Carter (highvoltage) wrote:
> Hi Eriberto
>
> On 07/01/2016 01:28, Eriberto Mota wrote:
>> Other datail is that is a good idea upload the first version to
>> experimental to see how to the library will build. So you will able to
>> can fix the issues (if necessary) an
%:
>> dh $@
>>
>> override_dh_makeshlibs:
>> dh_makeshlibs -- -v$(PVER)
>
>
> No, please don't do this.
IMO, it is right and works fine. What is the specific problem? The
symbol file can be a minimal collection of symbols to generate all
symbols in each arch. F
* Eriberto Mota , 2016-01-06, 21:28:
dpkg-gensymbols: warning: debian/libkpmcore1/DEBIAN/symbols doesn't
match completely debian/libkpmcore1.symbols
--- debian/libkpmcore1.symbols (libkpmcore1_1.9.50-1_amd64)
+++ dpkg-gensymbolsBiEPCo 2016-01-06 20:58:15.171645367 -0200
@@ -1195,3 +11
Hi Eriberto
On 07/01/2016 01:28, Eriberto Mota wrote:
Other datail is that is a good idea upload the first version to
experimental to see how to the library will build. So you will able to
can fix the issues (if necessary) and reupload to unstable.
I hope this help.
Yes thanks that's very val
Hi Jonathan,
Initially, your package doesn't build in a fresh jail because needs
extra-cmake-modules, libkf5kdelibs4support-dev and pkg-config in
Build-Depends field. Please, always use cowbuilder or pbuilder to test
if your package builds.
About the symbols, the problem is that dpkg-gensy
* Jonathan Carter , 2016-01-06, 15:13:
I'm attempting to package kpmcore, a shared library for partitioning
tasks in KDE. I'm not sure if my dpkg symbols index for the shared
library file gets used because it doesn't contain a debian revision,
yet lintian says that it does on my
Hi Debian Mentors
I'm attempting to package kpmcore, a shared library for partitioning
tasks in KDE. I'm not sure if my dpkg symbols index for the shared
library file gets used because it doesn't contain a debian revision, yet
lintian says that it does on my binary package (inspec
Your message dated Wed, 6 Jan 2016 13:03:28 + (UTC)
with message-id <1827948725.1292711.1452085408238.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#810090: Info received (Bug#810090: RFS: eclib -- code
for modular symbols and elliptic curves over Q)
has caused the Debian Bug
Hi,
Signed&Uploaded, thanks for your contribution to Debian!
>I don't think that update will require a transition.
reverse-depends -b libec-dev
reverse-depends libec-dev
reverse-depends libec2
returned nothing, so I sponsored the package.
there is no need for a Debian transition, but it m
: GPL-2+
Section : math
It builds those binary packages:
eclib-tools - Programs for modular symbols and elliptic curves over Q
libec-dev - Library for modular symbols and elliptic curves over Q
(developme
libec2 - Library for modular symbols and elliptic curves over Q
Hi Jakub,
> * Herbert Parentes Fortes Neto , 2015-11-30, 16:50:
> >>That said, I wonder if there's any point in passing -V to
> >>dh_makeshlibs if the package uses symbols. It doesn't seem useful.
> >
> >The option started to be used in version 2.4.1-1
* Herbert Parentes Fortes Neto , 2015-11-30, 16:50:
That said, I wonder if there's any point in passing -V to
dh_makeshlibs if the package uses symbols. It doesn't seem useful.
The option started to be used in version 2.4.1-1 (2008),
I believe. From debian/changelog:
* New upstre
ssed -X options to dh_makeshlibs. They are needed to
> prevent debhelper from treating private libraries like if they were
> shared libraries (see bug #205142).
Ok.
>
> >dpkg-gensymbols: warning: new libraries appeared in the symbols file:
> >
> >dpkg-gensymbols
t debhelper from treating private libraries like if they were
shared libraries (see bug #205142).
dpkg-gensymbols: warning: new libraries appeared in the symbols file:
dpkg-gensymbols: warning: debian/libgphoto2-6/DEBIAN/symbols
doesn't match completely debian/libgphoto2-6.sym
Hi,
I didn't understand how this work.
The package has 2 .symbols files. One was
updated when the ABI was changed (2.5.7).
I forgot about the other. So I made new
.symbols files for the last version (2.5.9).
ABI-compatible.
I removed the 'override_dh_makeshlibs' and
now '
Hi Jakub,
> * Herbert Parentes Fortes Neto , 2015-11-26, 12:15:
> >I maintain a package which provides a .symbols file. But it uses a
> >dh_makeshlibs in debian/rules[0].
> >
> >override_dh_makeshlibs:
> > dh_makeshlibs -plibgphoto2-$(major) \
>
* Herbert Parentes Fortes Neto , 2015-11-26, 12:15:
I maintain a package which provides a .symbols file. But it uses a
dh_makeshlibs in debian/rules[0].
override_dh_makeshlibs:
dh_makeshlibs -plibgphoto2-$(major) \
-V 'libgphoto2-$(major) (>= $(SHLIBS))' \
Hi,
I maintain a package which provides a .symbols
file. But it uses a dh_makeshlibs in debian/rules[0].
override_dh_makeshlibs:
dh_makeshlibs -plibgphoto2-$(major) \
-V 'libgphoto2-$(major) (>= $(SHLIBS))' \
-X/usr/lib/$(DEB_HOST_MULTIARC
Thanks for your input!
Cheers,
Nico
On Thu, Nov 19, 2015 at 1:27 PM Ghislain Vaillant
wrote:
> On 19/11/15 11:55, Jakub Wilk wrote:
> > * Nico Schlömer , 2015-11-18, 22:52:
> >> I'm building the symbols for all libraries in the Trilinos package.
> >> Unfortunat
On 19/11/15 11:55, Jakub Wilk wrote:
* Nico Schlömer , 2015-11-18, 22:52:
I'm building the symbols for all libraries in the Trilinos package.
Unfortunately, the documentation [1] isn't too verbose here. One thing
that has come to my attention, for example, is the fact that som
* Nico Schlömer , 2015-11-18, 22:52:
I'm building the symbols for all libraries in the Trilinos package.
Unfortunately, the documentation [1] isn't too verbose here. One thing
that has come to my attention, for example, is the fact that some
Trilinos libraries appear to contain lots
Hi everyone,
I'm building the symbols for all libraries in the Trilinos package.
Unfortunately, the documentation [1] isn't too verbose here. One thing that
has come to my attention, for example, is the fact that some Trilinos
libraries appear to contain lots of symbols; including some
compiler for debianaze .
> e.g. ld thing.o -lqdb -lthingqbneeds
> So if libqdb needs symbols from libthingqdbneeds it will error like
> this.
>
> Sometimes the dpkg-buildflags (correctly) trips these things up. I've
> found them a useful check for getting upstream in
iler errors, including
> the compiler command that failed is absolute minimum.
Especially for this one, the common problem here is that the order of
options is wrong.
e.g. ld thing.o -lqdb -lthingqbneeds
So if libqdb needs symbols from libthingqdbneeds it will error like
this.
Sometimes the d
te minimum.
* "J.S.Júnior" , 2015-09-04, 14:22:
/usr/bin/ld: src/Daemon/usbguard_daemon-Daemon.o: undefined reference
to symbol 'qb_ipcs_create'
//usr/lib/x86_64-linux-gnu/libqb.so.0: error adding symbols: DSO
missing from command line
I think you need to add the library providing that s
Hello Forum,
my current working package distributes a same C library with several flavours:
technically they are different but they share the same map (script version).
My concern is the .symbols files. They will be very similar, in fact only their
header is different: is there a way to share the
* Sune Vuorela , 2014-04-04, 08:01:
It's a pkgkde-symbolshelper(1)'s (from the pkg-kde-tools package)
thing. But AFIACS pkgkde-symbolshelper doesn't have any documentation,
so the “is not explained” still holds. :/
http://pkg-kde.alioth.debian.org/symbolfiles.html
If it's not in the manpage
1 - 100 of 261 matches
Mail list logo
