Bug#1062184: [Pkg-electronics-devel] Bug#1062184: gnucap: NMU diff for 64-bit time_t transition
On Wed, Jan 31, 2024 at 03:36:36PM +, Lukas Märdian wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > gnucap as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Dear Lukas. Thanks for your work. I'm very certain that we do not use time_t anywhere. Certainly not explicitly, and there is no time_t mentioned in any library interface, leave alone header file. Hence I believe this is a false positive. To remain on the safe side, i'm happy to investigate the assessment if needed. Feel free to provide any log files or evidence from the analysis. Best wishes felix
Bug#924822: adms is marked for autoremoval from testing
On Mon, Mar 25, 2019 at 04:39:08AM +, Debian testing autoremoval watch wrote: > adms 2.3.6-1 is marked for autoremoval from testing on 2019-04-15 > > It is affected by these RC bugs: > 924822: adms: FTBFS: admstpathYacc.y:14604: error: unterminated > argument list invoking macro "adms_message_error" possibly related to the perl/yaml upgrade in testing. could not reproduce the reported issue. but found a similar issue. there is a typo in admsXml/Makefile.am & FTBFS for me. -verilogYacc.h: verilogYacc.c +verilogaYacc.h: verilogaYacc.c with this [1] it appears to work. hth felix [1] https://salsa.debian.org/science-team/adms/commit/4852d662a19017eac73a6b518cedc5eff80a9ea6
Bug#919255: [Pkg-electronics-devel] Bug#918533: gnucap-python: diff for NMU version 0.0.2-1.1
On Sun, Jan 20, 2019 at 07:33:44PM +0100, Mattia Rizzolo wrote: > Then if you don't mind I'd still keep my NMU as it is and let it enter > unstable. The only thing is that you'd find yourself to integrate it > into your own tree. no worries. will merge it. thanks felix
Bug#919255: [Pkg-electronics-devel] Bug#918533: gnucap-python: diff for NMU version 0.0.2-1.1
On Sun, Jan 20, 2019 at 04:34:28PM +0100, Mattia Rizzolo wrote: > If it's only about sponsoring I'm happy to help, but I don't really want > to play with symbols at this time… my preferred solution will be to accept the dpkg-shlibdeps warnings, as described in the manual. it will be more tricky to silence them. > With this and onther package being the only last blockers for the > removal of python3.6 I'm somewhat pressured to continue, unless you can > give me a shorter ETA. Also, I'm happy to rework my work. I essetially agree with your changes. the ETA is subject to review & sponsoring. > On that note, looking at the git repository I see that: > * you didn't do anything to d/rules, that still mention 3.6 and 3.7 I used a symlink to make tests work across python versions. currently the tests are not active, due to numerical noise. I had planned to clean up d/rules after reworking the tests upstream, when re-enabling the tests. > * you are build-depending on python3-dev, instead of python3-all-dev, > is that wanted? As I went for the letter in my NMU. looks reasonable. i simply did not know about it. > Also, while working on gnucap-python, I had the feeling that those > out2.7 and out3.6 directories were pre-built stuff that shouldn't be in out* contains the expected output for testing, which varies across python versions. it actually shouldn't, and it does not between 3.7 and 3.6. perhaps out2 and out3 will be sufficient. work in progress, possibly ready in 0.0.3. thanks felix
Bug#919255: [Pkg-electronics-devel] Bug#918533: gnucap-python: diff for NMU version 0.0.2-1.1
On Sun, Jan 20, 2019 at 01:55:18PM +0100, Mattia Rizzolo wrote: > I've prepared an NMU for gnucap-python (versioned as 0.0.2-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Dear Mattia. thanks for your commitment. I have prepared 0.0.2-2 in the pkg-electronics team repo, looking for a sponsor. we are now discussing issues with toolchains [2], ETA unknown. Please proceed as you wish. regards felix [1] https://salsa.debian.org/electronics-team/Gnucap/gnucap-python.git [2] https://alioth-lists.debian.net/pipermail/pkg-electronics-devel/2019-January/thread.html#5887
Bug#914355: [Pkg-electronics-devel] Bug#914355: gnucap-python: FTBFS (dh_auto_configure fails)
On Thu, Nov 22, 2018 at 04:35:20PM +, Santiago Vila wrote: > Package: src:gnucap-python > Version: 0.0.0-1 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package but it failed: Thank you. there's a new package for the 0.0.1 release [1]. the build issue caused by incomplete python dependencies is fixed. this was one reason for 914355. i checked with cowbuilder for amd64 and i386. on i386, only the tests fail due to numerical noise. please advise if that can wait until 0.0.2, ETA unknown. (i don't think there is a use case for gnucap on i386..) regards felix [1] https://salsa.debian.org/electronics-team/Gnucap/gnucap-python
Bug#830681: trilinos-all-dev: Updating binutils breaks trilinos
On Mon, Jul 18, 2016 at 11:18:30AM +, Nico Schlömer wrote: > [binutils] just turn it off > > @Felix Agreed? sure, makes sense! let's postpone the static link bfd thing. thank you felix
Bug#830681: trilinos-all-dev: Updating binutils breaks trilinos
On Sun, Jul 10, 2016 at 12:07:11PM +0200, Massimiliano Leoni wrote: > The latest update of binutils to version 2.26.1-1 makes it imopssible to > compile against trilinos. The linker complains > > /usr/bin/ld: warning: libbfd-2.26-system.so, needed by > > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libtrilinos_teuchoscore.so, > not found (try using -rpath or -rpath-link) interesting. the trilinos-teuchos12 package depends on binutils (>= 2.26), binutils (<< 2.27) if that's correct, we shouldn't link libtrilinos_teuchoscore.so to a particular revision of libbfd-2.26-system.so. how would that be possible? otoh, if libbfd-2.26.1-system.so - is meant to replace libbfd-2.26-system.so, shouldn't there be a symlink? - is NOT meant to provide libbfd-2.26-system.so, then why are these not coinstallable? I'm not trying to argue that this is a bug in binutils, i just don't understand. my idea would be to change the binutils dependency to (=2.26), but that feels a bit silly (isn't that dependency automatic?). cheers felix
Bug#707347: sage build failure
Hi there.
trying to compile/package sagelib (the core library of the sagemath project) i
am running into a similar issue.
upstream ppl might have already resolved this. from ppl.hh:
/*
[..]
\note
The PPL provides the specializations of the class template
numeric_limits not only for PPL-specific numeric types,
but also for the GMP types mpz_class and
mpq_class. These specializations will be removed
as soon as they will be provided by the C++ interface of GMP.
*/
If you dont intend to pull in a new ppl release: for me it worked to simply
enclose the two "template <> class numeric_limits { [..] };"
prototypes into "#ifndef __GMP_PLUSPLUS__ .. #endif". I'd highly appreciate a
working package...
thank you
felix
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
