Bug#1017822: ITP: vart -- Vitis AI RuntTime library
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: vart Version : 2.5 Upstream Author : Xilinx Inc. * URL : https://github.com/Xilinx/Vitis-AI * License : Apache-2.0 Programming Lang: C++ Description : Vitis AI RuntTime library Vitis AI RunTime is an application level runtime interface for DPU IPs based on XRT. It use XIR subgraph as input, and runs it on different targets. There are also emulators implemented with same interface to make debuging eaiser.
Re: Epoch for node-markdown-it
Quoting Pirate Praveen (2022-08-20 23:01:07) > > > On ശ, ഓഗ 20, 2022 at 3:53 വൈകു, Holger Levsen > wrote: > > On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote: > >> > > Epochs cause problems, [...] > >> > which are? (I agree they are ugly and should often be avoided, > >> but I don't > >> > see any unsolved problems with them, which is why I'm asking.) > >> The standard one is that people use them to revert an upload. > > > > ok, I agree that's bad. (but not the case here.) > > > >> But, epochs aren't used in the upstream tarball filename, so you > >> then > >> easily get a conflict between the old and the new one. > > > > I'd replace 'easily' with 'theoretically in rare cases' but I can see > > how > > this is a valid point, sometimes. > > I think the only real consequence for this is a dak reject which can be > fixed by a new upload with +debian suffix. > > Say when upstream again release 22.3 version, 1:22.3 orig.tar will have > a different checksum from 22.3 orig.tar. If at all dak keeps history of > the tar after so many releases. At that point, just uploading > 1:22.3+debian will allow dak to accept the new tarball. Am I missing > something here? > > If this is indeed the case, it feels like many people are blindly > chanting epoch is evil without really understanding what is at stake > really. What I find bad about epochs is that declaring dependencies becomes tricky: When you need to declare a "newer than" dependency it is easy to miss the need for the epoch prefix, and the mistake easily goes unnoticed. I dislike your accusation that your fellow developers are cluelessly ranting about this. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Epoch for node-markdown-it
]] Holger Levsen > On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote: > > Epochs cause problems, [...] > > which are? (I agree they are ugly and should often be avoided, but I don't > see any unsolved problems with them, which is why I'm asking.) IIRC, they're not recorded in the file name in the archive, so foo-1.0-1 and foo-1:1.0-1 will have the same file names. This isn't a huge problem in practice since epochs are often the result of an upstream switching from a date-based release model to a semver(-ish) model, such as 2022-03 → 1.2, but in this particular case, it can lead to these problems if/when upstream reaches 22 as their major version number. I'm not sure how snapshot will handle it, as one of the few services that care about this over decades, rather than just the active set of releases. (Or maybe dak just denies you reusing the file name and the uploader gets an error message, I don't know.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#1017843: ITP: python-hyperglot -- Detect language support for font binaries
Package: wnpp Severity: wishlist Owner: Agathe Porte X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org * Package name: hyperglot Version : 0.4.0 Upstream Authors: Johannes Neumeier - Rosetta URL : https://github.com/rosettatype/hyperglot * License : GNU GPLv3 Description : Detect language support for font binaries Hyperglot helps type designers answer a seemingly simple question of language support in fonts: When can I use font A to set texts in language B? It takes a pragmatic answer by identifying a standard character set for each orthography used by a language. The database that currently contains information for over 640+ languages is a work in progress, designed to grow. This package is a new dependency for the gftools package. I intent to maintain this package under the umbrella of the Debian Python Team.
Bug#1017844: ITP: python-axisregistry -- Access data from the Google Fonts variable fonts axis registry
Package: wnpp Severity: wishlist Owner: Agathe Porte X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org * Package name: python-axisregistry Version : 0.3.5 Upstream Authors: Felipe Sanches URL : https://github.com/googlefonts/axisregistry/ * License : Apache-2.0 Description : Access data from the Google Fonts variable fonts axis registry This repository contains a python package providing easy access to the GF Axis Registry. Data was copied (and is kept is sync with) its original location at the `axisregistry` directory on the https://github.com/google/fonts git repo. . As of March 4th, 2022, there's an ongoing plan to soon make this module the central place for updates on the data-set. This package is a new dependency for the gftools package. I intent to maintain this package under the umbrella of the Debian Python Team.
Proposed MBF: packages still using nose
Hi, nose [1] is a testing framework for Python, which is dead and unmaintained since 2015 [2][3]. The former maintainer of nose recommends projects using nose to switch to nose2 [4], pytest [5] or unittest from Python standard library [6]. There is a script called nose2pytest [7] which can assist with migrating from nose to pytest. nose has a Python 2 code base and it is difficult to keep it in working state for new Python versions. It will probably become impossible after Python 3.13, where lib2to3 will be removed [8]. In Debian sid, we still have 389 packages which either build-depend on nose or use it in autopkgtests. I propose to file bugs for them asking to switch to a supported alternative. A dd-list is attached. [1]: https://tracker.debian.org/pkg/nose [2]: https://github.com/nose-devs/nose/commit/0f40fa995384afad [3]: https://pypi.org/project/nose/#history [4]: https://docs.nose2.io/en/latest/ [5]: https://docs.pytest.org/en/latest/ [6]: https://docs.python.org/3/library/unittest.html [7]: https://github.com/pytest-dev/nose2pytest [8]: https://docs.python.org/3/library/2to3.html#module-lib2to3 -- Dmitry Shachnev Adrian Vondendriesch flask-mongoengine (U) Adrien Vergé yamllint (U) Afif Elghraoui falcon (U) optlang (U) swiglpk (U) Aggelos Avgerinos imbalanced-learn (U) py-radix (U) Agustin Henze webassets Aigars Mahinovs isbnlib python-dlt python-zipstream Alastair McKinstry metaconfig Alexandre Viau influxdb-python (U) Alvin Chen requirement-parser Ana Custura namecheap python-cymruwhois tldextract yapf Andreas Beckmann piuparts (U) Andreas Metzler libvigraimpex (U) Andreas Tille fastaq (U) iva (U) paleomix (U) python-biom-format (U) python-nose-random (U) python-pbcore (U) python-pyani (U) python-pymummer (U) python-pynndescent (U) pyutilib (U) qiime (U) scoary (U) umap-learn (U) youtube-dl Andrej Shadura docker-compose (U) netplan.io (U) sortedcontainers (U) Andrew Chadwick mypaint (U) Andrew Starr-Bochicchio fabric (U) pyxdg (U) Andrey Rahmatullin dateparser (U) Andrius Merkys xraylarch (U) anonym onionshare (U) Antoine Beaupré dateparser (U) python-invoke (U) Antoine Musso python-statsd (U) voluptuous (U) Antonio Terceiro python-ofxclient (U) rows (U) Antonio Valentino pysph (U) python-hdf4 (U) Apollon Oikonomopoulos ripe-atlas-cousteau (U) ripe-atlas-sagan (U) ripe-atlas-tools Arno Töll dput-ng (U) Arthur de Jong python-pskc python-stdnum Arto Jantunen python-inflect (U) Bas Couwenberg python-mapnik (U) python-stetl (U) Bdale Garbee rocketcea Ben Finney python-lockfile Benda Xu vitables (U) Benjamin Drung python-redmine Benjamin Drung modernize (U) python-ipmi (U) Bernd Zeimetz flask-wtf (U) Brian May celery (U) django-nose (U) python-passlib (U) BW Keller yt (U) Carl Chenet python-memcache (U) Carlos Maddela rmlint Carsten Schoenert kicad (U) kopano-webapp (U) kopanocore (U) ChangZhuo Chen (陳昌倬) dodgy (U) prospector (U) python-requirements-detector (U) python-setoptconf (U) voltron (U) Chris Boot nrpe-ng Chris Johnston python-flake8 (U) Chris Lamb django-assets (U) Christian Kastner imbalanced-learn (U) scikit-learn (U) tpot (U) Christian M. Amsüss sparql-wrapper-python (U) Christopher Hoskin case (U) pytds (U) sphinx-celery (U) Clément Hermann onionshare (U) Colin Watson py-macaroon-bakery (U) python-libnacl (U) Colin Watson git-build-recipe Corey Bryant murano (U) Dain Nilsson python-yubico (U) Daniel Kahn Gillmor pdfminer (U) Daniele Tricoli pdfminer (U) Daniele Tricoli pywavelets (U) David Douard chaussette David Paleino python-nmap (U) uncertainties (U) David Watson python-anyjson (U) Debian Astronomy Maintainers galpy pytest-mpl Debian Astronomy Team yt Debian Authentication Maintainers python-yubico Debian Cloud Team python-boto Debian Electronics Team kicad Debian FreeIPA Team freeipa Debian FreeIPA Team python-jwcrypto Debian GIS Project python-descartes python-geopandas python-hdf4 python-mapnik python-stetl Debian Let's Encrypt Team pyrfc3339 (U) Debian Med Packaging Team bcbio biomaj3 biomaj3-cli biomaj3-core biomaj3-daemon biomaj3-download biomaj3-process biomaj3-user cwlformat falcon fastaq gfapy imbalanced-learn insilicoseq iva mirtop neo nibabel nipy paleomix pynn python-biom-format python-deeptools python-fitbit python-gffutils python-gtfparse python-mne python-pbcore python-pyani python-pybedtools python-pymummer python-seqcluster python-sqt pyxnat q2-diversity-lib q2-quality-filter
Bug#1017846: ITP: debugbreak -- Put breakpoints in C/C++ code
Package: wnpp Severity: wishlist Owner: Fukui Daichi X-Debbugs-Cc: debian-devel@lists.debian.org, a.dog.will.t...@akane.waseda.jp * Package name: debugbreak Version : 1.0 Upstream Author : Scott Tsai * URL : https://github.com/scottt/debugbreak * License : BSD-2-Clause Programming Lang: C, Python Description : Put breakpoints in C/C++ code Reason for ITP: c4core depends on this utility [0]. rapidyaml [1] depends on c4core. Moreover, jsonnet [2] depends on rapidyaml. [0] https://github.com/biojppm/c4core/blob/v0.1.9/.gitmodules [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003397 [2] https://tracker.debian.org/pkg/jsonnet Maintenance plan: Because I am a novice in debian packaging, I would like to ask for someone who can review my upload. I need a sponsor too.
Re: Proposed MBF: packages still using nose
Dear Dmitry, Il 21/08/22 15:04, Dmitry Shachnev ha scritto: Hi, nose [1] is a testing framework for Python, which is dead and unmaintained since 2015 [2][3]. The former maintainer of nose recommends projects using nose to switch to nose2 [4], pytest [5] or unittest from Python standard library [6]. There is a script called nose2pytest [7] which can assist with migrating from nose to pytest. nose has a Python 2 code base and it is difficult to keep it in working state for new Python versions. It will probably become impossible after Python 3.13, where lib2to3 will be removed [8]. In Debian sid, we still have 389 packages which either build-depend on nose or use it in autopkgtests. I propose to file bugs for them asking to switch to a supported alternative. A dd-list is attached. [1]:https://tracker.debian.org/pkg/nose [2]:https://github.com/nose-devs/nose/commit/0f40fa995384afad [3]:https://pypi.org/project/nose/#history [4]:https://docs.nose2.io/en/latest/ [5]:https://docs.pytest.org/en/latest/ [6]:https://docs.python.org/3/library/unittest.html [7]:https://github.com/pytest-dev/nose2pytest [8]:https://docs.python.org/3/library/2to3.html#module-lib2to3 -- Dmitry Shachnev nose.dd-list.txt ... Antonio Valentino pysph (U) python-hdf4 (U) I have just uploaded a new version of the python-hdf4 package in which the dependency on nose has bee removed (replaced by pytest). Regarding pysph, the package in unstable is already OK. It should be able to migrate once #1010961 and #1015009 (removal of binary packages form unstable) are resolved. Apparently it takes some time but I hope that pysph will be able to migrate soon. kind regards -- Antonio Valentino
Re: Bug#1017716: ITP: muon-meson -- Meson-compatible build system
Il giorno ven 19 ago 2022 alle 14:43:27 -07:00:00, Russ Allbery ha scritto: Debian specifically disallows providing the same binary path from multiple packages in cases where the two binaries do not do the same thing with roughly the same arguments [1]. It would create a situation where /usr/bin/muon on different Debian systems can do wildly different things depending on what packages are installed or even on what order in which they're installed. That in turn creates user confusion, can cause weird problems, etc. It's just too surprising for users for the same binary to be entirely different things on different Debian systems with the same major release installed. Thanks, thinking about this a bit more made me realize that yeah, it's better not to do this. As mentioned by Vincent, I'll try asking the Qt/KDE team about this conflict. Thank you all for the feedback! -- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
Re: Automatic trimming of changelogs in binary packages
Hello, On Fri 19 Aug 2022 at 11:44AM GMT, Bastien Roucariès wrote: > > Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit : >> Hello, >> >> in 2020 there was a brief discussion on debian-devel@ about trimming >> changelogs [1,2]. >> >> Now there is a working implementation of said functionality in >> `dh_installchangelogs` [3]. > Could you stress on the mapage that some license ask to document the change > done by downstream in binary distribution and that in this case this tool > should be disable I think our separation of orig.tar and diff.gz/whatever has this covered? -- Sean Whitton signature.asc Description: PGP signature
Re: Automatic trimming of changelogs in binary packages
On Fri, Aug 19, 2022 at 11:44:03AM +, Bastien Roucariès wrote: > Le jeudi 18 août 2022, 19:18:35 UTC Gioele Barabucci a écrit : > > Hello, > > > > in 2020 there was a brief discussion on debian-devel@ about trimming > > changelogs [1,2]. > > > > Now there is a working implementation of said functionality in > > `dh_installchangelogs` [3]. > Could you stress on the mapage that some license ask to document the change > done by downstream in binary distribution and that in this case this tool > should be disable Like GPLv2's "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change"? We already don't do this. -- WBR, wRAR signature.asc Description: PGP signature
Re: Epoch for node-markdown-it
Hello, On Sat 20 Aug 2022 at 03:53PM GMT, Holger Levsen wrote: > > On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote: >> > > Epochs cause problems, [...] >> > which are? (I agree they are ugly and should often be avoided, but I don't >> > see any unsolved problems with them, which is why I'm asking.) >> The standard one is that people use them to revert an upload. > > ok, I agree that's bad. (but not the case here.) > >> But, epochs aren't used in the upstream tarball filename, so you then >> easily get a conflict between the old and the new one. > > I'd replace 'easily' with 'theoretically in rare cases' but I can see how > this is a valid point, sometimes. > > Thanks for the feedback. Epochs make it easier to accidentally violate Policy 3.2.2. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017877: ITP: reload4j -- Drop-in replacement for Apache log4j 1.2 Java logging framework
Package: wnpp Severity: wishlist Owner: tony mancill X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: reload4j Version : 1.2.22 Upstream Author : Ceki Gülcü * URL : https://reload4j.qos.ch/ * License : Apache 2.0 Programming Lang: Java Description : Drop-in replacement for Apache log4j 1.2 Java logging framework The reload4j project is a fork of Apache log4j version 1.2.17 in order to fix most pressing security issues. It is intended as a drop-in replacement for log4j version 1.2.17. By drop-in, we mean the replacement of log4j.jar with reload4j.jar in your build without needing to make changes to source code, i.e., to your java files. With release 1.2.18.0 and later, the reload4j project offers a clear and easy migration path for the thousands of users who have an urgent need to fix vulnerabilities in log4j 1.2.17. This is being packaged because it is a dependency of slf4j [1] since version 1.7.33 (Debian currently ships version 1.7.32 [2]) and because a number of upstream projects have switched to reload4j. Having a separate reload4j source package will allow us to provide a clean transition from liblog4j1.2-java -> libreload4j-java and fully EOL Apache log4j 1.2. [1] https://www.slf4j.org/ [2] https://tracker.debian.org/pkg/libslf4j-java signature.asc Description: PGP signature
Is there a mip64el machine available for debugging?
The list at https://db.debian.org/machines.cgi suggests all available machines are "buildd" and restricted. I need to debug a build problem that appears only on mips64el. And only since the new glibc. Is there any known issues with the new glibc on mips64el? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Re: Is there a mip64el machine available for debugging?
On 8/22/22 05:36, Steven Robbins wrote: The list at https://db.debian.org/machines.cgi suggests all available machines are "buildd" and restricted. eller.debian.org is the mipsel/mips64el porterbox. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Is there a mip64el machine available for debugging?
Oh. I did use Eller -- but the architecture is listed as mipsel. I need mips64el On August 21, 2022 10:54:44 p.m. CDT, Sebastiaan Couwenberg wrote: >On 8/22/22 05:36, Steven Robbins wrote: >> The list at https://db.debian.org/machines.cgi suggests all available >> machines >> are "buildd" and restricted. > >eller.debian.org is the mipsel/mips64el porterbox. > >Kind Regards, > >Bas > >-- > GPG Key ID: 4096R/6750F10AE88D4AF1 >Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Is there a mip64el machine available for debugging?
On 8/22/22 07:15, Steve Robbins wrote: Oh. I did use Eller -- but the architecture is listed as mipsel. I need mips64el eller has mips64el chroots too, just like there are i386 chroots on the amd64 porterbox: sebastic@eller:~$ schroot -l | grep mips64el chroot:bookworm-backports_mips64el-dchroot chroot:bookworm_mips64el-dchroot chroot:bullseye-backports_mips64el-dchroot chroot:bullseye_mips64el-dchroot chroot:buster-backports_mips64el-dchroot chroot:buster_mips64el-dchroot chroot:experimental_mips64el-dchroot chroot:sid_mips64el-dchroot source:bookworm-backports_mips64el-dchroot source:bookworm_mips64el-dchroot source:bullseye-backports_mips64el-dchroot source:bullseye_mips64el-dchroot source:buster-backports_mips64el-dchroot source:buster_mips64el-dchroot source:experimental_mips64el-dchroot source:sid_mips64el-dchroot https://dsa.debian.org/doc/schroot/ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Is there a mip64el machine available for debugging?
On Mon, Aug 22, 2022 at 08:08:30AM +0200, Sebastiaan Couwenberg wrote: > On 8/22/22 07:15, Steve Robbins wrote: > > Oh. I did use Eller -- but the architecture is listed as mipsel. I need > > mips64el > > eller has mips64el chroots too, just like there are i386 chroots on the > amd64 porterbox: > > sebastic@eller:~$ schroot -l | grep mips64el > chroot:bookworm-backports_mips64el-dchroot > chroot:bookworm_mips64el-dchroot > chroot:bullseye-backports_mips64el-dchroot > chroot:bullseye_mips64el-dchroot > chroot:buster-backports_mips64el-dchroot > chroot:buster_mips64el-dchroot > chroot:experimental_mips64el-dchroot > chroot:sid_mips64el-dchroot > source:bookworm-backports_mips64el-dchroot > source:bookworm_mips64el-dchroot > source:bullseye-backports_mips64el-dchroot > source:bullseye_mips64el-dchroot > source:buster-backports_mips64el-dchroot > source:buster_mips64el-dchroot > source:experimental_mips64el-dchroot > source:sid_mips64el-dchroot > > https://dsa.debian.org/doc/schroot/ For more ease, you could consider to use Enrico's script here[1] All you then need is $ debug-on-porterbox mips64el --host eller.debian.org [1]: https://salsa.debian.org/enrico/debug-on-porterbox -- Best, Nilesh signature.asc Description: PGP signature
Re: Proposed MBF: packages still using nose
On Sun, 21 Aug 2022 16:04:36 +0300 Dmitry Shachnev wrote: > Hi, > > nose [1] is a testing framework for Python, which is dead and > unmaintained since 2015 [2][3]. > > The former maintainer of nose recommends projects using nose to > switch to nose2 [4], pytest [5] or unittest from Python standard > library [6]. There is a script called nose2pytest [7] which can > assist with migrating from nose to pytest. xraylarch (U) Fixed in git. -- Neil Williams = https://linux.codehelp.co.uk/ pgpnnISiYOXxe.pgp Description: OpenPGP digital signature
