> I suspect that many optional symbols on the symbols file of this package
> could be squashed with a regex, but alas I can't help with that now
> since I'll be soon leaving for a 2-weeks travel and I don't think I
> would ever find the time to also look at this. Anyway, look at the gdcm
> repo fo
On Wed, Dec 05, 2018 at 07:50:30PM +0100, Gregor Riepl wrote:
> I'm inclined to drop the symbols file altogether, as it really doesn't add any
> value.
I beg to disagree, I tend to find symbols tracking quite important, and
helped detecting and/or demostrating several ABI breakages in the past
whe
I'm inclined to drop the symbols file altogether, as it really doesn't add any
value. The correct solution would be to use -fvisibility=hidden [1] and
properly tag symbols for the public API of libArcus and libSavitar.
For what it's worth, libArcus.so.3 is currently only used by python3-arcus and
> Hi, I saw that you asked for sponsorship on the ML¹ but then pere failed
> to build the package². Could you please have a look soon?
Sorry, got held up by the mess that is symbols files for C++ libraries that
don't properly hide internal symbols.
I'll try to get this sorted out ASAP.
Do you k
On Thu, Nov 29, 2018 at 08:23:48AM +0100, Gregor Riepl wrote:
> Ok, it looks like I misunderstood how binNMUs work, so I'll simply prepare a
> release then. [1]
Hi, I saw that you asked for sponsorship on the ML¹ but then pere failed
to build the package². Could you please have a look soon?
¹
Ok, it looks like I misunderstood how binNMUs work, so I'll simply prepare a
release then. [1]
[1] https://wiki.debian.org/binNMU
> for the Python 3.7 default transition, libarcus was binNMUed against
> Python 3.7, but FTBFS on at least amd64, arm64, i386, mips, ppc64el
> and s390x:
>
> https://buildd.debian.org/status/package.php?p=libarcus&suite=unstable
>
> So far it only build fine only on these release architectures" arm
7 matches
Mail list logo
