Re: symbols-File for Library
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 toolchain might have influences, are
> > architecture dependent and once you think you've got it you'll get the
> > next breakage… I'd just override the warning and be done.
>
> What do you do for the library shlibs in that case? Use == $version?
${shlibs:Depends}
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
Re: symbols-File for Library
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-gensymbols and had > dpkg-gensymbols generate a debian/libgensio0.symbols file, added the > Build-Depends-Package line and did the mentioned conversions regarding > C++ libraries. > > Still, the build on i386 fails since the symbols file looks different on > i386 than it does on amd64. See > https://salsa.debian.org/debian/gensio/-/jobs/3093727 > > The repository can be inspected at > https://salsa.debian.org/debian/gensio/-/tree/master > > I guess this behavior is expected since you can have symbols file per > arch as debian/libgensio0.symbols.$ARCH. But how do I generate those? > > Do I really need to build on all arches and/or guess what's needed in > the arch-dependent symbol file from the logs of failed buildd runs? This > looks like an awful lot of work that has to be repeated for every > upstream update? I suggest uploading new upstream releases to experimental to know the behavior in each architecture. For MISSING lines, an easy fix is to exclude the fault architectures. E.g. to exclude i386 and x32: (arch=!i386 !x32)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*, gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" Cheers, Eriberto
Re: symbols-File for Library
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 you think you've got it you'll get the > next breakage… I'd just override the warning and be done. What do you do for the library shlibs in that case? Use == $version? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Environment variable for package base dir
Hi,
one of my packages
https://salsa.debian.org/debian-astro-team/sep
requires to specify a path relative to the package base dir (the path to
a shared library), which is important for build and for testing. I,
Python, it is specified in setup.py.
I solved this the following way:
d/rules:
export BUILD_ROOT=$(shell pwd)
setup.py (patched):
buildroot = os.environ.get('BUILD_ROOT', '.')
This works nicely locally (cowbuilder) and in Salsa. However, on the
buildds, the build root is set empty and the build fails.
What is the normal way to get the package build root?
Best
Ole
Bug#1016875: RFS: freefilesync/11.23-1 [ITP] -- cross-platform file sync utility, gpl release
Hi, On Thu, Aug 11, 2022 at 03:27:14PM -0400, Boyuan Yang wrote: > * You indicated "Multi-Arch: foreign" in debian/control file. However > according to https://wiki.debian.org/MultiArch/Hints#ma-foreign , M-A: > foreign only applies to Architecture: all packages. Your package is not of > Architecture: all. To clarify, the mentioned wiki explains how the Multi-Arch hinter comes up with its suggestions. In this specific section how a package which ticks all the boxes can surely be marked M-A:foreign. Packages who do not tick (all) the boxes could be valid candidates for M-A:foreign as well, its just that an automated process like the hinter can't decide that in the general case.¹ I suppose this package could be marked M-A:foreign as it likely has no architecture-specific interfaces but that needs to be checked to be sure. I also suppose that it is not very useful to mark it as such in any case as it looks like a GUI and those tend to be leaf packages, but M-A only comes into play if other packages (build-)depend on your package. So I would recommend to refrain from setting M-A:foreign for this package until you are either REALLY SURE its the correct thing to do OR some other Debian contributor tells you they need you to set it. Best regards David Kalnischkies ¹ sed for example is M-A:foreign even though it is arch:any as the output it produces does not change regardless of you running it on amd64 or armhf. A compiler like gcc on the other hand produces output (= machine code) specific to the architecture it runs on and hence can not be marked M-A:foreign (And than an interpreter like python3 comes along and it becomes complicated. Also, this is a gross simplification). signature.asc Description: PGP signature
Bug#1016875: RFS: freefilesync/11.23-1 [ITP] -- cross-platform file sync utility, gpl release
X-Debbugs-CC: fabstz...@yahoo.fr Control: tags -1 +moreinfo Hi, On Mon, 08 Aug 2022 19:30:32 +0200 Fab Stz wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "freefilesync": > > * Package name : freefilesync > Version : 11.23-1 > Upstream Author : Zenju > * URL : https://freefilesync.org/ > * License : GPL-3.0 > * Vcs : https://salsa.debian.org/bastif/freefilesync > Section : utils > > The source builds the following binary packages: > > freefilesync - cross-platform file sync utility, gpl release > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/freefilesync/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x https://mentors.debian.net/debian/pool/main/f/freefilesync/ > freefilesync_11.23-1.dsc I am curious on the current arrangement of your deb packaging. Specifically: * Why there are many separate ffs_* patches in debian/patches/? Where did they originate from? If they originates from upstream (FreeFileSync), why aren't they incorporated into upstream source code? * You are providing .desktop files under debian/desktop/. Does that mean that upstream author is not providing any .desktop files so that you have to write them yourself? * Please do not hardcode g++-12:native in the Build-Depends field. A sane environment should already have provided the proper g++. It could be g++ 12 or other versions. * You wrote Maintainer: B. Stack in debian/control file, which looks falty to me. The maintainer should be package maintainer, not upstream software author, unless the upstream author (B. Stack) will be maintaining Debian package as well. * You indicated "Multi-Arch: foreign" in debian/control file. However according to https://wiki.debian.org/MultiArch/Hints#ma-foreign , M-A: foreign only applies to Architecture: all packages. Your package is not of Architecture: all. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1017022: RFS: docarray/0.14.8-1 [ITP] -- provides the data structure for unstructured multimodal data.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "docarray": * Package name: docarray Version : 0.14.8-1 Upstream Author : Jina AI Limited * URL : https://docarray.jina.ai * License : Apache-2.0, Expat * Vcs : http://salsa.debian.org/debian/docarray Section : science The source builds the following binary packages: python3-docarray - provides the data structure for unstructured multimodal data. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/docarray/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/docarray/docarray_0.14.8-1.dsc Changes for the initial release: docarray (0.14.8-1) unstable; urgency=low . * Initial release. (Closes: #1016907) Can the sponsor please create the debian repo for this package in salsa? I have a local version of this repo at https://salsa.debian.org/jtoh/docarray Regards, -- Jack Toh
Re: symbols-File for Library
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 > dpkg-gensymbols generate a debian/libgensio0.symbols file, added the > Build-Depends-Package line and did the mentioned conversions regarding > C++ libraries. > > Still, the build on i386 fails since the symbols file looks different on > i386 than it does on amd64. See > https://salsa.debian.org/debian/gensio/-/jobs/3093727 > > The repository can be inspected at > https://salsa.debian.org/debian/gensio/-/tree/master > > I guess this behavior is expected since you can have symbols file per > arch as debian/libgensio0.symbols.$ARCH. But how do I generate those? > > Do I really need to build on all arches and/or guess what's needed in > the arch-dependent symbol file from the logs of failed buildd runs? This > looks like an awful lot of work that has to be repeated for every > upstream update? > > Or am I missing something here? My experience with symbol files and C++ is: It's a nightmare. 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 you think you've got it you'll get the next breakage… I'd just override the warning and be done. -- tobi
symbols-File for Library
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 and did the mentioned conversions regarding C++ libraries. Still, the build on i386 fails since the symbols file looks different on i386 than it does on amd64. See https://salsa.debian.org/debian/gensio/-/jobs/3093727 The repository can be inspected at https://salsa.debian.org/debian/gensio/-/tree/master I guess this behavior is expected since you can have symbols file per arch as debian/libgensio0.symbols.$ARCH. But how do I generate those? Do I really need to build on all arches and/or guess what's needed in the arch-dependent symbol file from the logs of failed buildd runs? This looks like an awful lot of work that has to be repeated for every upstream update? Or am I missing something here? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
