Help with Lintian error in python3 (pybind11-wrapped) package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I'm adding a new python3 package as part of a larger C++ package [1], which builds using a rather standard dh + cmake procedure, then builds a python3 package from a pybind11 wrapper. The problem I have found is that lintian keeps complaining about: E: python3-pymrpt: python-package-missing-depends-on-python Finished running lintian. despite the package has "python3" explicitly written by hand in d/control [2]. I attach the output of "dpkg -I" for the final binary package, where the "Depends: python3" is visible, so I don't know if this is a lintian false positive or I'm missing something... hopefully you can help me out with this! :-) Also, any help looking at the d/control section for the new python3 package in [2] to spot any possible problem would be appreciated! Cheers, JL [1] https://salsa.debian.org/robotics-team/mrpt [2] https://salsa.debian.org/robotics-team/mrpt/-/blob/master/debian/control#L956-964 - -- /** * Jose Luis Blanco-Claraco * Universidad de Almería - Departamento de Ingeniería * [Homepage]( https://w3.ual.es/~jlblanco/ ) * [GH profile]( https://github.com/jlblancoc ) */ -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.4.8 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAnBYJkq78aCZDUQzBPvXCmQRYhBHf2neQjGKO3Aa2EZNRDME+9 cKZBAACZsQ/+MQw0KdbHGhDWmAe9BG9ecdAtmYZLfWNlmw+WMjlEPpN+cZ7T NcspxH/J3qhmQ8z9V/xPnfU4nfoXJj2ua7kmHJTwye51VF0LGlpDJFldRTVv 8QFK/AcvqOu23/vIhf/y6EyhMk5e0ASNsl02cIcJjpWz72RHjUyA68QHz0fs nlIcyFGoeueIZJduVdzLgQwN4qz8IE+nD8zOMzWujUycFjiQLjq9/fSRD0kw a2VRjth+1auwz0rMu28YU7GEgK1SMi2PNESJVTmfFUMCDCSNHRW7205IcHpb kFAP/n56xPj54nqOive7tHPAzKGF7ihhYAspzTXKF92eR02PuU6EXqAmr6tz P36+PU1b+GCzmrBtb0HN9+rrbA+gL5M8r1xitEq6iIvda+4UonNEbPj3hBQy e2ssa4i/i1NH2ZEHXteQRFBPBZ079f//1/5RhPbGzuKMSjC83gzcfzUZ303R LLh0C5GuqCdBT56OfPfDPGET06MOTdgkAqPqfKK/w+6JN8EBEBtot4veLhQy 4TjxScsCTXo44yQcE13WnC6ZBMRUOee337OTAtmztf1CsvTn5fmLJ0Jkylkc DJZD2YOHS7zVWjSGygoFgEyOPLVtNCRozspQjldElRjOhROweotgWchzFXDT tK0aBovseoa48bVBcfrOSQ+NyLsqyhubcuY= =1opa -END PGP SIGNATURE- dpkg -I python3-pymrpt_2.10.0+ds-1_amd64.deb new Debian package, version 2.0. size 4967520 bytes: control archive=2604 bytes. 1763 bytes,18 lines control 5888 bytes,62 lines md5sums Package: python3-pymrpt Source: mrpt Version: 1:2.10.0+ds-1 Architecture: amd64 Maintainer: Jose Luis Blanco Claraco Installed-Size: 27772 Depends: phyton3, libc6 (>= 2.34), libgcc-s1 (>= 3.3.1), libmrpt-apps2.10 (>= 1:2.10.0+ds), libmrpt-bayes2.10 (>= 1:2.10.0+ds), libmrpt-comms2.10 (>= 1:2.10.0+ds), libmrpt-config2.10 (>= 1:2.10.0+ds), libmrpt-containers2.10 (>= 1:2.10.0+ds), libmrpt-core2.10 (>= 1:2.10.0+ds), libmrpt-expr2.10 (>= 1:2.10.0+ds), libmrpt-graphs2.10 (>= 1:2.10.0+ds), libmrpt-gui2.10 (>= 1:2.10.0+ds), libmrpt-hwdrivers2.10 (>= 1:2.10.0+ds), libmrpt-img2.10 (>= 1:2.10.0+ds), libmrpt-io2.10 (>= 1:2.10.0+ds), libmrpt-kinematics2.10 (>= 1:2.10.0+ds), libmrpt-maps2.10 (>= 1:2.10.0+ds), libmrpt-math2.10 (>= 1:2.10.0+ds), libmrpt-nanogui2.10 (>= 1:2.10.0+ds), libmrpt-nav2.10 (>= 1:2.10.0+ds), libmrpt-obs2.10 (>= 1:2.10.0+ds), libmrpt-opengl2.10 (>= 1:2.10.0+ds), libmrpt-poses2.10 (>= 1:2.10.0+ds), libmrpt-random2.10 (>= 1:2.10.0+ds), libmrpt-rtti2.10 (>= 1:2.10.0+ds), libmrpt-serialization2.10 (>= 1:2.10.0+ds), libmrpt-slam2.10 (>= 1:2.10.0+ds), libmrpt-system2.10 (>= 1:2.10.0+ds), libmrpt-tfest2.10 (>= 1:2.10.0+ds), libmrpt-topography2.10 (>= 1:2.10.0+ds), libmrpt-vision2.10 (>= 1:2.10.0+ds), libstdc++6 (>= 11) Section: python Priority: optional Multi-Arch: same Homepage: https://www.mrpt.org/ Description: Python wrapper for MRPT The Mobile Robot Programming Toolkit (MRPT) is an extensive, cross-platform, and open source C++ library aimed to help robotics researchers to design and implement algorithms in the fields of Simultaneous Localization and Mapping (SLAM), computer vision, and motion planning (obstacle avoidance). . This package contains a Python 3 wrapper for the C++ MRPT libraries. 0xD443304FBD70A641.asc Description: application/pgp-keys
Re: golang-github-azuread-microsoft-authentication-library-for-go_1.0.0-1_amd64.changes REJECTED
On Tue, 4 Jul 2023 at 22:07, M Hickford wrote: > On Tue, 4 Jul 2023 at 19:00, Thorsten Alteholz > wrote: > > > > > > Hi, > > > > according to LICENSE the copyright holder is Microsoft Corporation !? > > Hi Thorsten. Is that a problem? > > I see, > https://salsa.debian.org/go-team/packages/golang-github-azuread-microsoft-authentication-library-for-go/-/blob/debian/sid/LICENSE > and > https://salsa.debian.org/go-team/packages/golang-github-azuread-microsoft-authentication-library-for-go/-/blob/debian/sid/debian/copyright > are inconsistent. I'll correct. > > Uploaded package with corrected debian/copyright to > > https://mentors.debian.net/package/golang-github-azuread-microsoft-authentication-library-for-go/ > . > Thank you mentors for all your help so far > > > > > > Thorsten > > > > > > > > === > > > > Please feel free to respond to this email if you don't understand why > > your files were rejected, or if you upload new files which address our > > concerns. > > > Is anyone able to kindly sponsor this package?
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 01:19:38AM -0700, JOSE LUIS BLANCO CLARACO wrote: > [2]. I attach the output of "dpkg -I" for the final binary package, where > the "Depends: python3" is visible No, as it says "phyton3". (I would also expect that using appropriate substvars here is better than writing deps manually)
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:02 AM gregor herrmann wrote: > phyton3 != python3 > :) hahaha, I knew more eyeballs would be helpful! Thanks a lot, Gregor, that solves the mystery :-)
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> No, as it says "phyton3".
> (I would also expect that using appropriate substvars here is better than
> writing deps manually)
I know, and added ${python3:Depends} and ${shlibs:Depends}, but
"dh-python" seems not to add any substvars, and "shlibs" does neither.
In fact, the "so" module built from the pybind11 wrapper seems not to
list any python library in "ldd", which also puzzled me:
ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x7facb732d000)
but the module loads perfectly from python3 scripts/interpreter, etc.
I checked that other "*cpython.so" modules out there indeed list
"libpython3.xxx.so" in their "ldd".
I understand this is what is preventing "shlibs" to automatically list
python3 as a substvar, but don't know how to fix it.
This is my first python3 package, so I don't feel confident about how
things should work.
Neither found an equivalent pybind11-based wrapper packaged in Debian
for reference, so any further pointers would be appreciated!.
JL
--
/**
* Jose Luis Blanco-Claraco
* Universidad de Almería - Departamento de Ingeniería
* [Homepage]( https://w3.ual.es/~jlblanco/ )
* [GH profile]( https://github.com/jlblancoc )
*/
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, 10 Jul 2023 01:19:38 -0700, JOSE LUIS BLANCO CLARACO wrote: > I attach the output of "dpkg -I" for the final binary package, where > the "Depends: python3" is visible, Copied from the attached file: Depends: phyton3 phyton3 != python3 :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- BOFH excuse #193: Did you pay the new Support Fee?
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> > No, as it says "phyton3".
> > (I would also expect that using appropriate substvars here is better than
> > writing deps manually)
>
> I know, and added ${python3:Depends} and ${shlibs:Depends}, but
> "dh-python" seems not to add any substvars, and "shlibs" does neither.
shlibs:Depends is indeed irrelevant here.
python3:Depends being empty is a problem that needs to be fixed. I've
built the package and it lacks postinst/prerm so I guess dh_python3 didn't
find any modules in the package. I also see that the package is named
python3-pymrpt while the top-level module is named myrpt, though I don't
know if this can cause any problems beside the autopkgtest not working.
> In fact, the "so" module built from the pybind11 wrapper seems not to
> list any python library in "ldd", which also puzzled me:
>
> ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
> libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x7facb732d000)
Python extensions indeed don't need to link libpython, which is (mostly?)
for embedding the interpreter, as extensions are loaded into an
interpreter themselves.
> I checked that other "*cpython.so" modules out there indeed list
> "libpython3.xxx.so" in their "ldd".
(I've checked two random extensiopns and they don't)
> I understand this is what is preventing "shlibs" to automatically list
> python3 as a substvar, but don't know how to fix it.
It's not, and shlibs:Depends won't list python3 anyway.
Bug#1026335: carl9170 needs to wait on a new gcc-sh-elf upload
Control: tags -1 moreinfo I've discovered an issue with how the Built-Using fields are generated. Specifically, because gcc-sh-elf does not set a Built-Using field for Newlib, and because of the way the libnewlib-sh-elf-dev binary package is currently versioned, there is no way to precisely tell what version of the Newlib source package was used to generate libnewlib-sh-elf-dev and hence which gets baked into the carl9170 binaries. That means we can't set the Built-Using field right. Fortunately this does not have to be fixed in Newlib: it can be fixed completely in gcc-sh-elf, so I will simply prepare a new upload that changes the format of the version numbers so we can tell what version of the Newlib source package was used. When ready, I will send an RFS for that package and mark it as blocking this one. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1040788: RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices
Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net Control: block 1026335 by -1 Dear mentors, I am looking for a sponsor for my package "gcc-sh-elf": * Package name : gcc-sh-elf Version : 7 * License : various * Vcs : https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf Section : devel The source builds the following binary packages: gcc-sh-elf - GNU C compiler for embedded SuperH devices libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH devices To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gcc-sh-elf/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_7.dsc Changes since the last upload: gcc-sh-elf (7) unstable; urgency=medium . * Include the full used Newlib source package version number in the libnewlib-sh-elf-dev binary package version number. This is necessary so we can tell what source package version was used. This is a one-line change in debian/rules that is necessary for us to set the correct Built-Using field for carl9170fw; see that RFS to see the details spelled out. By the time you're reading this, if the moreinfo tag is removed from carl9170fw, then that's ready to go too and would also appreciate your careful review. I will push changes to Git once this is uploaded. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: Help with Lintian error in python3 (pybind11-wrapped) package
Thanks a lot, Andrey, for the time analyzing the problems here, and
for the clarifications. I thought libpython was like "libc" for
python...
So the main issue seems to be dh_python3 not recognizing the package
as "python"...
I attach the list of files and directories of the latest package
version just in case it's easy to spot problems from it (the
"__pycache__" are there for a test Ubuntu build, but are not in the
Debian build).
Note that I want to ship:
- A cpython .so module + its .pyi stubs.
- The corresponding py.typed file, which I understand is
recommended/mandatory when shipping .pyi stubs.
- Pure python scripts (right now, only "ros_bridge.py").
At present, I put everything under
"/usr/lib/python3/dist-packages/mrpt/" so everything is together, not
"polluting" the "dist-packages" directory.
Maybe the package should be named "python3-mrpt" instead?
Any way to test dh_python3 manually? Perhaps just build the package
locally and run dh_python3 from the pkg root directory?
Best,
JL
On Mon, Jul 10, 2023 at 2:58 PM Andrey Rakhmatullin wrote:
>
> On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> > On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> > > No, as it says "phyton3".
> > > (I would also expect that using appropriate substvars here is better than
> > > writing deps manually)
> >
> > I know, and added ${python3:Depends} and ${shlibs:Depends}, but
> > "dh-python" seems not to add any substvars, and "shlibs" does neither.
> shlibs:Depends is indeed irrelevant here.
> python3:Depends being empty is a problem that needs to be fixed. I've
> built the package and it lacks postinst/prerm so I guess dh_python3 didn't
> find any modules in the package. I also see that the package is named
> python3-pymrpt while the top-level module is named myrpt, though I don't
> know if this can cause any problems beside the autopkgtest not working.
>
> > In fact, the "so" module built from the pybind11 wrapper seems not to
> > list any python library in "ldd", which also puzzled me:
> >
> > ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
> > libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1
> > (0x7facb732d000)
> Python extensions indeed don't need to link libpython, which is (mostly?)
> for embedding the interpreter, as extensions are loaded into an
> interpreter themselves.
>
> > I checked that other "*cpython.so" modules out there indeed list
> > "libpython3.xxx.so" in their "ldd".
> (I've checked two random extensiopns and they don't)
>
> > I understand this is what is preventing "shlibs" to automatically list
> > python3 as a substvar, but don't know how to fix it.
> It's not, and shlibs:Depends won't list python3 anyway.
>
--
/**
* Jose Luis Blanco-Claraco
* Universidad de Almería - Departamento de Ingeniería
* [Homepage]( https://w3.ual.es/~jlblanco/ )
* [GH profile]( https://github.com/jlblancoc )
*/
python3-pymrpt_2.10.1~20230709-1304-git-1ea114bb~lunar-1_amd64.deb
--
new Debian package, version 2.0.
size 5599708 bytes: control archive=2659 bytes.
2601 bytes,17 lines control
6102 bytes,64 lines md5sums
Package: python3-pymrpt
Source: mrpt
Version: 1:2.10.1~20230709-1304-git-1ea114bb~lunar-1
Architecture: amd64
Maintainer: Jose Luis Blanco Claraco
Installed-Size: 28338
Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.3.1), libmrpt-apps2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-bayes2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-comms2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-config2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-containers2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-core2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-expr2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-graphs2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-gui2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-hwdrivers2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-img2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-io2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-kinematics2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-maps2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-math2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-nanogui2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-nav2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-obs2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-opengl2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-poses2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-random2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-rtti2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~lunar), libmrpt-serialization2.9 (>=
1:2.10.1~20230709-1304-git-1ea114bb~
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 05:11:39PM +0200, José Luis Blanco-Claraco wrote: > Thanks a lot, Andrey, for the time analyzing the problems here, and > for the clarifications. I thought libpython was like "libc" for > python... It is, but as extensions are loadable plugins, they are fine with symbols being provided by the executable instead of linking a library. If you check you will see that Py* symbols in the extensions are unresolved and that /usr/bin/python3 exports them. > So the main issue seems to be dh_python3 not recognizing the package > as "python"... > I attach the list of files and directories of the latest package > version just in case it's easy to spot problems from it (the > "__pycache__" are there for a test Ubuntu build, but are not in the > Debian build). TBH I don't think it's about the file list (though it's possible). > Note that I want to ship: > - A cpython .so module + its .pyi stubs. > - The corresponding py.typed file, which I understand is > recommended/mandatory when shipping .pyi stubs. > - Pure python scripts (right now, only "ros_bridge.py"). > > At present, I put everything under > "/usr/lib/python3/dist-packages/mrpt/" so everything is together, not > "polluting" the "dist-packages" directory. I don't think this makes sense. You should put them wherever the upstream puts them so that the module can be imported (and scripts can be run) in the way that is documented and expected by users. > Maybe the package should be named "python3-mrpt" instead? It should always be named for its top-level importable module, see https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names > Any way to test dh_python3 manually? Perhaps just build the package > locally and run dh_python3 from the pkg root directory? Yes. And you should run it in the verbose mode.
Bug#1040303: magpie/0.9.2-1 [ITP] -- Window manager and compositor library for the Budgie Desktop)
Hi, I have taken the opportunity to simplify the packaging - one less binary and no longer needs postinst and preinst scripts Please accept this version as a sponsorship request The source builds the following binary packages: gir1.2-magpie-0 - GObject introspection data for magpie libmagpie-0-0 - window manager library from the magpie window manager libmagpie-0-dev - Development files for the magpie window manager magpie-common - shared files for the magpie window manager To access further information about this package, please visit the following URL: https://mentors.debian.net/package/magpie/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/magpie/magpie_0.9.2-1.dsc Changes since the last upload: magpie (0.9.2-1) experimental; urgency=medium . * Initial Release (Closes: #1040005)
Bug#1040804: RFS: cdw/1.0-2 [ITA] -- Tool for burning CD's - console version
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "cdw": * Package name : cdw Version : 0.8.1-3 Upstream contact : https://sourceforge.net/projects/cdw/support * URL : https://cdw.sourceforge.net/ * License : GPL-2+ Section : otherosfs The source builds the following binary packages: cdw - Tool for burning CD's - console version To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cdw/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cdw/cdw_0.8.1-3.dsc Changes since the last upload: cdw (0.8.1-3) unstable; urgency=medium . * New maintainer (Closes: #1001962). * debian/control: - Change Maintainer. - Change libncurses5-dev and libncursesw5-dev dependencies to libncurses-dev. - Update Standards-Version to 4.6.2. - Add Rules-Requires-Root to no. * debian/copyright: - Add new maintainer. - Clean file up, better formatting. * debian/upstream/metadata: - Add basic upstream meta-information. Regards, -- Matteo Bini Dear Laszlo Boszormenyi, I would love to be the new maintainer of cdw, a software I use and like. I've emailed upstream regarding the required change of libraries and I've received their blessing to keep maintaining the software. I hope to start working on the migration from wodim and genisoimage to xorriso and libburnia this summer. In the meantime, I hope I can release you from your duties for this package. Thank you for your work so far. -- Matteo Bini
Bug#1040788: marked as done (RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices)
Your message dated Mon, 10 Jul 2023 23:16:38 +0200 with message-id and subject line Re: RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices has caused the Debian Bug report #1040788, regarding RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices 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.) -- 1040788: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040788 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net Control: block 1026335 by -1 Dear mentors, I am looking for a sponsor for my package "gcc-sh-elf": * Package name : gcc-sh-elf Version : 7 * License : various * Vcs : https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf Section : devel The source builds the following binary packages: gcc-sh-elf - GNU C compiler for embedded SuperH devices libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH devices To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gcc-sh-elf/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_7.dsc Changes since the last upload: gcc-sh-elf (7) unstable; urgency=medium . * Include the full used Newlib source package version number in the libnewlib-sh-elf-dev binary package version number. This is necessary so we can tell what source package version was used. This is a one-line change in debian/rules that is necessary for us to set the correct Built-Using field for carl9170fw; see that RFS to see the details spelled out. By the time you're reading this, if the moreinfo tag is removed from carl9170fw, then that's ready to go too and would also appreciate your careful review. I will push changes to Git once this is uploaded. signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature --- End Message --- --- Begin Message --- Thanks for the update.--- End Message ---
Bug#1026335: RFS: carl9170fw/1.9.9-427-gecb68a7-1 [ITP] -- firmware for AR9170 USB wireless adapters
Hi John, Please do not just ignore the comment: On Mon, 26 Dec 2022 18:58:14 +0100 Bastian Germann wrote: The reason why I requested you to reopen the old RFS instead of filing a new one is that you have not yet addressed all of pabs's comments: On Wed, 05 Jan 2022 09:49:13 +0800 Paul Wise wrote: > Several files have missing/incorrect information in debian/copyright, > please do a full audit of the code looking for copyright/license info. > > * tools/include/list.h is LGPL Please note it is LGPL-2.1, not LGPL-2.1+. There is no or later clause. > * tools/include/frame.h is partly from Linux, unknown copyright Please use the authors for copyright: Alan Cox, Florian La Roche, > * include/shared/eeprom.h also contains ISC code Please add the missing info for the three mentioned files.
