schroot behaves different than pbuilder (Was: Bug#963392: [Help] Re: r-cran-rstanarm: FTBFS: error: (converted from warning) TBB library not found.)
Hi, the short version of this question is how can it be that pbuilder seems to "eat" some '-L' in front of a linker option in r-cran-rstan[1] to make the build fail in pbuilder (see below) while Shayan confirmed schroot is able to build the package nicely? Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-rstan On Thu, Sep 24, 2020 at 01:17:18PM +0100, Shayan Doust wrote: > Hello Andreas, > > That is very strange. It seems like a localised issue with chroot? It's > strange > because I can build this with sbuild (which relies on chroot?). I have > attached > the full log of my build regarding r-cran-rstan for information on the build > in > my case. > > I don't use chroots but I do rely on $ pbuilder login in some cases, so I'm > not > sure why you can't build this in your chroot. > > Kind regards, > Shayan Doust > > On 24/09/2020 10:19, Andreas Tille wrote: > > On Wed, Sep 23, 2020 at 07:34:50PM +0100, Shayan Doust wrote: > >> This [commit] now rectifies the build issue for r-cran-prophet. > >> > >> I can build r-cran-prophet successfully after re-building r-cran-rstan > >> with the > >> new patch. > > > > Strange, when I try to build r-cran-rstan with your patch I get: > > > > g++ -std=gnu++14 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include" > > -I"../inst/include/boost_not_in_BH" -I"." -DBOOST_DISABLE_ASSERTS > > -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -DBOOST_NO_AUTO_PTR -D_REENTRANT > > -DSTAN_THREADS -I'/usr/lib/R/site-library/Rcpp/include' > > -I'/usr/lib/R/site-library/RcppEigen/include' > > -I'/usr/lib/R/site-library/BH/include' > > -I'/usr/lib/R/site-library/StanHeaders/include' > > -I'/usr/lib/R/site-library/RcppParallel/include'-fpic -g -O2 > > -fdebug-prefix-map=/build/r-base-OT058M/r-base-4.0.2=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > > -D_FORTIFY_SOURCE=2 -g -c stan/lang/grammars/whitespace_grammar_inst.cpp > > -o stan/lang/grammars/whitespace_grammar_inst.o > > g++ -std=gnu++14 -shared -L/usr/lib/R/lib -Wl,-z,relro -o rstan.so Module.o > > chains.o init.o misc.o pointer-tools.o sparse_extractors.o stan_fit_base.o > > stan_fit_rccp.o stanc.o stan/lang/ast_def.o > > stan/lang/grammars/bare_type_grammar_inst.o > > stan/lang/grammars/block_var_decls_grammar_inst.o > > stan/lang/grammars/expression07_grammar_inst.o > > stan/lang/grammars/expression_grammar_inst.o > > stan/lang/grammars/functions_grammar_inst.o > > stan/lang/grammars/indexes_grammar_inst.o > > stan/lang/grammars/local_var_decls_grammar_inst.o > > stan/lang/grammars/program_grammar_inst.o > > stan/lang/grammars/semantic_actions_def.o > > stan/lang/grammars/statement_2_grammar_inst.o > > stan/lang/grammars/statement_grammar_inst.o > > stan/lang/grammars/term_grammar_inst.o > > stan/lang/grammars/whitespace_grammar_inst.o /usr/lib/x86_64-linux-gnu > > -ltbb -ltbbmalloc -L/usr/lib/R/lib -lR > > /usr/bin/ld: cannot find /usr/lib/x86_64-linux-gnu: file format not > > recognized > > collect2: error: ld returned 1 exit status > > make[1]: *** [/usr/share/R/share/make/shlib.mk:6: rstan.so] Error 1 > > > > It looks as if some variable is not resloved properly resolved in the chroot > > I substituted > > > >s/inst.o /usr/lib/x86_64-linux-gnu -ltbb/inst.o > > -L/usr/lib/x86_64-linux-gnu -ltbb/ > > > > (in the very end) and it worked. I guess the patch in R/plugin.R is > > responsible > > for this since this is where I can find the string -ltbb. > > > > Any idea how to fix this? > > > > Kind regards > > > >Andreas. > > -- http://fam-tille.de
Bug#970859: marked as done (RFS: picom/8.1-1 -- lightweight compositor for X11)
Your message dated Thu, 24 Sep 2020 17:02:09 +0300 with message-id <20200924140209.ga7...@tsipinakis.com> and subject line RFS: picom/8.1-1 -- lightweight compositor for X11 has caused the Debian Bug report #970859, regarding RFS: picom/8.1-1 -- lightweight compositor for X11 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 970859: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970859 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "picom": * Package name: picom Version : 8.1-1 Upstream Author : Yuxuan Shui * URL : https://github.com/yshui/picom * License : Expat, MPL-2.0, Expat and MPL-2.0 * Vcs : https://salsa.debian.org/nikos/picom Section : x11 It builds those binary packages: picom - lightweight compositor for X11 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/picom/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/picom/picom_8.1-1.dsc Changes since the last upload: picom (8.1-1) unstable; urgency=medium . * New upstream version 8.1 Note: I'm a DM but don't currently have upload rights for this package -- Best Regards, Nikos Tsipinakis --- End Message --- --- Begin Message --- Dogsleg just granted me DM rights to picom so this RFS is redundant. Sorry for the noise. -- Best Regards, Nikos Tsipinakis--- End Message ---
Bug#970696: closing 970696
close 970696 thanks
Bug#970696: One more change
Uploaded! (Many thanks for ITSing)
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
On 24/09/2020 10:34, Tobias Frost wrote: > Control: tags -1 moreinfo > Control: reopen -1 > > On Thu, Sep 24, 2020 at 09:29:58AM +0200, Alec Leamas wrote: >> Hi again, >> >> On 24/09/2020 09:07, Alec Leamas wrote: > (Looking at the -dev package: they use a quite common filename (serial.h) > without subdirectory in /usr/include. I wonder if there are collisions > in the archvie…) If not, it would be because other packages are sane. This one is certainly not in this sense. Needs to be fixed (see below) > - Typo in d/changelog: s/FTBS/FTBFS/ Fixed. That was actually no typo, for some reason I have always used FTBS although it's obviously wrong. > - Please add the patch I sent in #970712#39… /me wants back to Fedora, where the only way to change a package is a commit in the dist-git repo. NMUs and free-running patches, I miss them all. OTOH, now I have now learnt and it will never happen again. "cough" New package on mentors: #4, timestamp:2020-09-24 11:08 There is a need for a bigger rewrite: - Refactor the cmake patch(es) - Add a doc subpackage. - Don't install serial.h directly under /usr/include. Please feel free to file a bug or two; I'm on it anyway (although perhaps not exact now). Cheers! --alec
Bug#970858: RFS: dunst/1.5.0-1 -- dmenu-ish notification-daemon
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dunst": * Package name: dunst Version : 1.5.0-1 Upstream Author : Nikos Tsipinakis * URL : https://dunst-project.org/ * License : BSD-3-clause, ISC * Vcs : https://salsa.debian.org/debian/dunst Section : x11 It builds those binary packages: dunst - dmenu-ish notification-daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dunst/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dunst/dunst_1.5.0-1.dsc Changes since the last upload: dunst (1.5.0-1) unstable; urgency=medium . * New upstream version 1.5.0 * d/control: Bump debhelper compat to 13 (no changes) * d/control: Bump standards version to 4.5.0 (no changes) * d/copyright: Update copyright years * d/patches: Refresh patches * d/patches: Fix typo in dunstify error message * d/control: Specify Rules-Requires-Root: no * d/copyright: Add upstream contact info Note: I'm a DM but don't currently have upload rights for this package -- Best Regards, Nikos Tsipinakis
Bug#970859: RFS: picom/8.1-1 -- lightweight compositor for X11
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "picom": * Package name: picom Version : 8.1-1 Upstream Author : Yuxuan Shui * URL : https://github.com/yshui/picom * License : Expat, MPL-2.0, Expat and MPL-2.0 * Vcs : https://salsa.debian.org/nikos/picom Section : x11 It builds those binary packages: picom - lightweight compositor for X11 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/picom/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/picom/picom_8.1-1.dsc Changes since the last upload: picom (8.1-1) unstable; urgency=medium . * New upstream version 8.1 Note: I'm a DM but don't currently have upload rights for this package -- Best Regards, Nikos Tsipinakis
Bug#970696: One more change
I included one more change to cross build with nocheck.
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Control: tags -1 moreinfo Control: reopen -1 On Thu, Sep 24, 2020 at 09:29:58AM +0200, Alec Leamas wrote: > Hi again, > > On 24/09/2020 09:07, Alec Leamas wrote: > > > >> "/usr/lib/i386-linux-gnu/pkgconfig" > > > I have made a new upload, only changing the last reference. Will make a > > comment on mentors once it's ready. > > > >> However it builds fine even after changing it, so I presume this > >> DPKGCONFIGDIR is just not used... > > > > > > It's minor mess, basically about the first patch which is too > > heavy-handed. > > > > I have made a new patch series for the build files which I will try to > > upstream. Yeah, had the same thoughts about the build system… (My bikeshed color'd be to use ctest, as they are using cmake already, this feels like a good match) > > The idea is to use it in next release, whether accepted or > > not. However, this is a major change which we should probably avoid at > > this point, just clearing the 1386 issue. Agree. > The new version is available on mentors (#3). Confirmed, it is building. It builds now and the pkconfig file looks also ok. (* on a freshly updated i386 pbuilder env) (Looking at the -dev package: they use a quite common filename (serial.h) without subdirectory in /usr/include. I wonder if there are collisions in the archvie…) > I have considered using 'make -C obj-*' instead of 'make -C > obj-$(DEB_HOST_GNU_TYPE)'. It's simpler, but perhaps too simple (?) Could work, as we're not building for multiple archs at the same time… - Typo in d/changelog: s/FTBS/FTBFS/ - Please add the patch I sent in #970712#39… -- tobi signature.asc Description: PGP signature
