Bug#1033605: ITP: sphinxcontrib-jquery -- extension to include jQuery on newer Sphinx releases
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: sphinxcontrib-jquery Version : 4.1 Upstream Contact: Adam Turner * URL : https://github.com/sphinx-contrib/jquery * License : 0BSD Programming Lang: Python Description : extension to include jQuery on newer Sphinx releases sphinxcontrib-jquery ensures that jQuery is always installed for use in Sphinx themes or extensions. To use it, add sphinxcontrib.jquery as a Sphinx extension. I am going to maintain this package under the Debian Python Team umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Proposed MBF: packages still using nose
On Sun, Aug 21, 2022 at 04:04:36PM +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. > > 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. Thanks to everyone who replied! MBF is now done and bugs can be seen here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-t...@lists.alioth.debian.org;tag=nose-rm -- Dmitry Shachnev signature.asc Description: PGP signature
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-f
Bug#1009902: ITP: pyqt6-webengine -- Python bindings for the Qt WebEngine framework
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyqt6-webengine Version : 6.3.0 Upstream Author : Riverbank Computing Limited * URL : https://riverbankcomputing.com/software/pyqtwebengine/intro * License : GPL Programming Lang: SIP Description : Python bindings for the Qt WebEngine framework PyQt6-WebEngine is a set of Python bindings for The Qt Company’s Qt WebEngine framework. The framework provides the ability to embed web content in applications and is based on the Chrome browser. The bindings sit on top of PyQt6 and are implemented as three separate modules corresponding to the different libraries that make up the framework. I am going to maintain it in the Debian Python Team, like pyqt5webengine. Packaging will be here: https://salsa.debian.org/python-team/packages/pyqt6-webengine/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1009244: ITP: pyqt6 -- Python bindings for Qt 6
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyqt6 Version : 6.2.3 Upstream Author : Riverbank Computing Limited * URL : https://riverbankcomputing.com/software/pyqt/intro * License : GPL Programming Lang: C++, Python Description : Python bindings for Qt 6 Qt is set of cross-platform C++ libraries that implement high-level APIs for accessing many aspects of modern desktop and mobile systems. These include location and positioning services, multimedia, NFC and Bluetooth connectivity, a Chromium based web browser, as well as traditional UI development. PyQt6 is a comprehensive set of Python bindings for Qt v6. It is implemented as more than 35 extension modules and enables Python to be used as an alternative application development language to C++ on all supported platforms including iOS and Android. PyQt6 may also be embedded in C++ based applications to allow users of those applications to configure or enhance the functionality of those applications. I am going to maintain it in the Debian Python Team, like PyQt5. Packaging will be here: https://salsa.debian.org/python-team/packages/pyqt6/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1005707: ITP: pyqt6-sip -- runtime module for Python extensions using SIP
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyqt6-sip Version : 13.2.1 Upstream Author : Riverbank Computing Limited * URL : https://pypi.org/project/PyQt6-sip/ * License : SIP or GPL-2 or GPL-3 Programming Lang: C, C++, Python Description : runtime module for Python extensions using SIP SIP is a collection of tools that makes it very easy to create Python bindings for C and C++ libraries. PyQt6.sip is a runtime module, it is used by PyQt6 and other Python extension modules built with SIP. I am going to maintain it in the Debian Python Team: https://salsa.debian.org/python-team/packages/pyqt6-sip/ -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Help required to determine why some packages are being installed
Hi David, and thanks for your reply! On Thu, May 27, 2021 at 04:28:08PM +0200, David Kalnischkies wrote: > The self-inflicted joy of avoiding a transitional package (see also the > other thread about transitional packages on d-d@ I should comment) and > of too strict dependencies (just because its the same source package > doesn't mean = is a good choice; >= would have avoided that mess). ☺ Who could know that a removed package could make such a mess? :) > Add the Breaks also to qtbase5-dev. Also, make that breaks versioned so > that you can reintroduce qt5-default if that turns out to be needed > (Lintian probably complains about it, too). Thanks for the suggestion! Adding such Breaks solves most of the problems. When I run “apt dist-upgrade”, apt no longer tries to remove libqt5gui5. When I was testing this, I tried to upgrade only a subset of packages using “apt install libqt5widgets5” (that package was installed, but running that command should upgrade all Qt packages). Unfortunately, when running this specific command, apt still wants to remove libqt5gui5 and install libqt5gui5-gles. But I think we can live with it, as most users who have not upgraded yet will probably use dist-upgrade (or full-upgrade). > Usually I would recommend reintroducing qt5-default, but as you > described it as a sid-user only problem it seems more beneficial to keep > it removed for everyone rather than to readd for sid only confusing > users who want to look up if a removal of qt5-default is okay or not. To be more precise, it is a problem for users of sid and testing who have not upgraded for a long time. Users of stable should be safe. Things are a bit worse in Ubuntu, where the bad qt5-default made it to a stable release. In any case, I discussed with my co-maintainer (Lisandro) and we don't want to readd qt5-default. -- Dmitry Shachnev
Re: Help required to determine why some packages are being installed
Hi again David and all! I want to ask for the help again. We determined that the reason for users getting libqt5gui5-gles installed is the qt5-default package. We removed it in October 2020 because it is no longer needed. But the latest version of that package that ever existed had this dependency: Depends: qtbase5-dev (= 5.14.2+dfsg-5) | qtbase5-gles-dev (>= 5.14.2+dfsg) The latest available version of qtbase5-dev cannot satisfy that dependency, but the latest version of qtbase5-gles-dev can! So for people who had qt5-default installed, apt tries to replace the normal Qt stack with -gles one to keep that dependency satisfied. It does so even if it's going to remove qt5-default anyway! As an attempt to solve this problem, I added "Breaks: qt5-default" to both qtbase5-gles-dev and libqt5gui5-gles packages yesterday [2]. I thought this would convince apt to not consider these packages as a way to satisfy qt5-default dependency. But that did not work :( I am attaching a log which was obtained as follows: - Use sid snapshot from 2020-10-28 (a day before qt5-default was removed). - Install qt5-default package. - Change sources.list to use current sid. - Upgrade apt to the latest version (just in case). - Run "apt -o Debug::pkgProblemResolver=yes full-upgrade". As can be seen in that log, apt still tries to remove libqt5gui5 and install libqt5gui5-gles. If it did not do that, it would have to remove only one package (qt5-default) and not three. Can you please give me any advice on how to prevent apt from doing that? [1]: https://tracker.debian.org/news/1187732/accepted-qtbase-opensource-src-5151dfsg-2-source-into-unstable/ [2]: https://tracker.debian.org/news/1241122/accepted-qtbase-opensource-src-gles-5152dfsg-4-source-into-unstable/ P.S. The suggestion from your last mail (see my quote below) did not work too. On Sat, Jan 30, 2021 at 08:51:09PM +0300, Dmitry Shachnev wrote: > Thanks for the suggestion! Having the reverse doesn’t hurt of course, so > I have just added it in [1] and will include in the next upload. Let’s see > if it makes things any better. > > [1]: https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/4064bf01d808094d -- Dmitry Shachnev root@mitya57:/# apt -o Debug::pkgProblemResolver=yes full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Starting pkgProblemResolver with broken count: 1 Starting 2 pkgProblemResolver with broken count: 1 Investigating (0) qt5-default:amd64 < 5.14.2+dfsg-6 @ii mK Ib > Broken qt5-default:amd64 Depends on qtbase5-dev:amd64 < 5.14.2+dfsg-6 -> 5.15.2+dfsg-5 @ii umU > (= 5.14.2+dfsg-6) Considering qtbase5-dev:amd64 0 as a solution to qt5-default:amd64 -2 Broken qt5-default:amd64 Depends on qtbase5-gles-dev:amd64 < none | 5.15.2+dfsg-4 @un uH > (>= 5.14.2+dfsg) Considering qtbase5-gles-dev:amd64 -1 as a solution to qt5-default:amd64 -2 Try Installing qtbase5-gles-dev:amd64 < none | 5.15.2+dfsg-4 @un uH > before changing qt5-default:amd64 Or group remove for qt5-default:amd64 Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: fontconfig fontconfig-config fonts-dejavu-core libavahi-client3 libavahi-common-data libavahi-common3 libboost-iostreams1.67.0 libboost-iostreams1.71.0 libboost-system1.67.0 libbrotli1 libbsd0 libcups2 libcwidget3v5 libdbus-1-3 libdouble-conversion3 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-dev libegl-mesa0 libegl1 libelf1 libevdev2 libexpat1 libfontconfig1 libfreetype6 libgbm1 libgl-dev libgl1 libgl1-mesa-dri libglapi-mesa libgles2 libglib2.0-0 libglu1-mesa libglu1-mesa-dev libglvnd0 libglx-dev libglx-mesa0 libglx0 libgraphite2-3 libgudev-1.0-0 libharfbuzz0b libice6 libicu67 libinput-bin libinput10 libjpeg62-turbo libllvm11 libmd0 libmd4c0 libmtdev1 libnss-nis libnss-nisplus libpciaccess0 libpcre2-16-0 libperl5.30 libpng16-16 libpthread-stubs0-dev libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5-gles libqt5network5 libqt5printsupport5 libqt5sql5 libqt5test5 libqt5widgets5 libqt5xml5 libsensors-config libsensors5 libsm6 libvulkan-dev libvulkan1 libwacom-common libwacom2 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-dev libx11-xcb1 libxau-dev libxau6 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-present0 libxcb-randr0 libxcb-render-util0 libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-sync1 libxcb-util0 libxcb-util1 libxcb-xfixes0 libxcb-xinerama0 libxcb-xinput0 libxcb-xkb1 libxcb1 libxcb1-dev libxdamage1 libxdmcp-dev libxdmcp6 libxext-dev libxext6 libxfixes3 libxkbcommon-x11-0 libxkbcommon0 libxml2 libxrender1 libxshmfence1 libxxf86vm1 libz3-4 perl-modules-5.30 qt5-qmake qt5-qmake-bin qtbase5-dev-tools qtchooser shared-mime-info ucf x11-common x11proto-core-dev x
Re: Help required to determine why some packages are being installed
Hi David, and thanks for your thorough reply and explanation! On Sat, Jan 30, 2021 at 12:15:01PM +0100, David Kalnischkies wrote: > To refine this: apt¹ picks the first alternative which is either: > 1. already installed and satisfying as is > 2. already installed, but needs an upgrade to satisfy > 3. not installed, but can (may) be and would satisfy > > [...] That was my understanding as well (and what you wrote below too). > That said, I find it a bit odd that only libqt5gui5-gles conflicts with > libqt5gui5. I doubt it will help apt, but it seems more honest to also > have the reverse. Fun fact: having it only on one side actually gives > the one having it a scoring advantage in apts conflict resolution, so > for apt it reads in fact like -gles is the preferred package of the > two making it less likely that apt holds back libqt5gui5. In practice > other score points should level the playing field for libqt5gui5 though. > (At least on my system more things depend on it than -gles provides). Thanks for the suggestion! Having the reverse doesn’t hurt of course, so I have just added it in [1] and will include in the next upload. Let’s see if it makes things any better. [1]: https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/4064bf01d808094d -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#962799: ITP: snowball-data -- test data for Snowball stemming algorithms
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: snowball-data Version : 0+20191003-1 Upstream Author : Snowball developers * URL : https://github.com/snowballstem/snowball-data * License : BSD-3-clause, GPL-3+, CC-BY-SA-3.0, CC-BY-SA-4.0 Programming Lang: none Description : test data for Snowball stemming algorithms Snowball provides access to efficient algorithms for calculating a "stemmed" form of a word. This is a form with most of the common morphological endings removed; hopefully representing a common linguistic base form. This is most useful in building search engines and information retrieval software; for example, a search with stemming enabled should be able to find a document containing "cycling" given the query "cycles". Snowball provides algorithms for several (mainly European) languages. It also provides access to the classic Porter stemming algorithm for English: although this has been superseded by an improved algorithm, the original algorithm may be of interest to information retrieval researchers wishing to reproduce results of earlier experiments. This package contains the test data, which is used by Snowball test suite. In March I discussed it with snowball maintainer on IRC and he said that the test data should be a separate source package. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#956113: ITP: pyqt5-sip -- SIP runtime module for use in PyQt5 and other projects
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: pyqt5-sip Version : 12.7.2 Upstream Author : Riverbank Computing Limited * URL : https://pypi.org/project/PyQt5-sip/ * License : SIP or GPL-2 or GPL-3 Programming Lang: C, C++, Python Description : SIP run-time module for use in PyQt5 and other projects Since SIP v5, upstream source consists of two parts: - The build system, which is already packaged as python3-sipbuild. - The runtime module, which the extensions built with SIP depend on. Upstream allows every project to use their own copy of SIP runtime. All projects from Riverbank Computing Ltd use a module named PyQt5.sip, and we will recommend packages of other projects to change them to use PyQt5.sip too. Technically, both sipbuild and the runtime module are maintained in a single upstream repository, but the build system is designed in a way that PyQt5.sip should be built from a separate tarball. I will maintain it under the umbrella of Debian Python Modules Team. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#955222: ITP: sphinxcontrib-serializinghtml -- sphinx extension which outputs "serialized" HTML files (json and pickle)
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: sphinxcontrib-serializinghtml Version : 1.1.4 Upstream Author : Sphinx team * URL : https://github.com/sphinx-doc/sphinxcontrib-serializinghtml * License : BSD-2-clause Programming Lang: Python Description : sphinx extension which outputs "serialized" HTML files (json and pickle) This builder uses a module that implements the Python serialization API (pickle, simplejson, phpserialize, and others) to dump the generated HTML documentation. The pickle builder is a subclass of it. This package has been split out of Sphinx and is needed by some of its reverse dependencies. I will maintain it under the umbrella of Debian Python Modules Team. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#953272: ITP: pyqt-builder -- PEP 517 compliant PyQt build system
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: pyqt-builder Version : 1.2.0 Upstream Author : Riverbank Computing Limited * URL : https://pypi.org/project/PyQt-builder/ * License : BSD (2-clause) Programming Lang: Python Description : PEP 517 compliant PyQt build system PyQt-builder is the PEP 517 compliant build system for PyQt and projects that extend PyQt. It extends the sip build system and uses Qt's ``qmake`` to perform the actual compilation and installation of extension modules. Projects that use PyQt-builder provide an appropriate ``pyproject.toml`` file and an optional ``project.py`` script. Any PEP 517 compliant frontend, for example ``sip-install`` or ``pip`` can then be used to build and install the project. This package is needed to replace the legacy build system of PyQt5. I will maintain it under the umbrella of Debian Python Modules Team. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#951459: ITP: sip5 -- Python bindings generator for C/C++ libraries
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: sip5 Version : 5.1.0 Upstream Author : Riverbank Computing Limited * URL : https://riverbankcomputing.com/software/sip/intro * License : SIP Programming Lang: C, Python Description : Python bindings generator for C/C++ libraries SIP is a collection of tools that makes it very easy to create Python bindings for C and C++ libraries. It was originally developed in 1998 to create PyQt, the Python bindings for the Qt toolkit, but can be used to create bindings for any C or C++ library. For example it is also used to generate wxPython, the Python bindings for wxWidgets. SIP comprises a set of build tools and a sip module. The build tools process a set of specification files and generates C or C++ code which is then compiled to create the bindings extension module. Several extension modules may be installed in the same Python package. Extension modules can be built so that they are are independent of the version of Python being used. In other words a wheel created from them can be installed with any version of Python starting with v3.5. sip4 already exists in Debian, this is an ITP for the next version, sip5. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#935421: ITP: jeepney -- pure Python D-Bus protocol client
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: jeepney Version : 0.4.1 Upstream Author : Thomas Kluyver * URL : https://gitlab.com/takluyver/jeepney * License : MIT Programming Lang: Python Description : pure Python D-Bus protocol client This is a low-level, pure Python D-Bus protocol client. It has an I/O-free core, and integration modules for different event loops. D-Bus is an inter-process communication system, mainly used in Linux. I am going to maintain this package under DPMT umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#923884: ITP: pyqt5webengine -- Python bindings for Qt WebEngine
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: pyqt5webengine Version : 5.12 Upstream Author : Riverbank Computing Limited * URL : https://www.riverbankcomputing.com/software/pyqtwebengine/intro * License : GPL-3 Programming Lang: Python Description : Python bindings for Qt WebEngine In pyqt5 5.12 the WebEngine buildings were split into a separate module. So we need a new source package to continue shipping python3-pyqt5.qtwebengine etc. Upstream name is PyQt5WebEngine. The number 5 in source package name is for consistency with existing pyqt5 and pyqt5chart source packages. I will maintain this package under the Debian Python Modules Team umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Wed, Nov 28, 2018 at 12:32:51PM -0800, Steve Langasek wrote: > I would caution against prematurely optimizing for build-time. Yes, > building the entire source package twice is a waste of resources, but it's > probably a drop in the bucket. My mail concert was not build-time, but our (maintainers’) time. For any changes in normal packages (e.g. packaging new upstream releases), we will need to carefully merge these changes into the -gles packages and remove the bits that are not needed there. > The reason not to build the two stacks from a single source package is that > the gl vs gles libraries are by design drop-in replacements for one another > - i.e.: they must have the same soname in order for the symbols magic to > work, which means they end up conflicting on the system. You *could* design > a system that allows them to be coinstallable via subdirectories and > manually-managed symlinks, but I doubt this is actually worth it in practice > for the number of packages affected. Ah, I understand now — you mean that to build both variants of e.g. Qt 3D, we will need to build-depend on both libqt5gui5 and libqt5gui5-gles, which are not co-installable. That is a valid reason for having two separate source packages. However maybe it will be possible to build at least two variants of qtbase from the same source, as that’s one ofthe most complicated Qt packages. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote: > $ grep-dctrl -n -sSource:Package -FDepends \ > -e > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>= > 5\.[0-9.]*\))(?|$),' \ > > /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_*binary-amd64_Packages > | sort -u > maliit-plugins > ovito > pyqt5 > qml-box2d > qt3d-opensource-src > qtbase-opensource-src > qtdeclarative-opensource-src > qtubuntu-cameraplugin-fake > stellarium > wallch > $ > > Every single other binary package that depends on libqt5gui5 (etc) in Ubuntu > 16.04 has an ORed dependency on libqt5gui5 | libqt5gui5-gles. Ah, this is interesting. The amount of packages will probably be larger in the current sid, but it should not be more than 20 packages. Plus there are packages which are using QT_OPENGL_ES macro for conditional compilation (as I mentioned in my previous mail), but there are also not many of them: gammaray goldendict gst-plugins-good1.0 kamoso krita leocad openclonk phonon-backend-gstreamer qtav qt-gstreamer qtwebkit-opensource-src qtwayland-opensource-src qtcharts-opensource-src > So perhaps someone in this thread is willing to put in this effort to > maintain 6 source packages, in order to avoid having to make a choice > between GL and GLES on arm64. I wonder if these can be new binaries in existing source packages, instead of separate source packages. Otherwise we will have too much code duplication, and also wasted time: for example, in qtbase-opensource-src, only src/gui needs to be built twice, and there is no need to built other submodules twice. We already have an example of double build inside the same source: on i386, src/corelib is built twice, with and without sse2 support. In any case, this task looks manageable. Maybe if I have time someday I will take care of it, but in the meantime volunteers are welcome. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
Hi Steve and all, On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote: > It is actually fairly easy to answer this question as well: simply identify > all the packages in the archive that depend on one of the known dual-stack > libraries, prepare dual stack packages that use the symbols file magic from > Ubuntu, rebuild all the reverse-dependencies, and identify all those > packages which are libraries and which end up with a dependency only on the > GL version of the package instead of a dependency on GL | GLES. > > A fair amount of compile time required to do this analysis, but relatively > little human time. Let me explain what the mentioned “symbols file magic” is: debian/libqt5gui5.symbols header has these lines: libQt5Gui.so.5 libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER# | libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER#, qtbase-abi-5-7-1 | libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER# So symbols that exist in both desktop OpenGL and GL ES builds get a dependency on libqt5gui5 | libqt5gui5-gles, and maybe on a -abi- virtual package if they are private. And symbols that exist in only one of flavours are getting the dependency only on the particular binary package name, e.g.: (optional)_ZN25QOpenGLFunctions_3_2_Core14versionProfileEv@Qt_5 5.2.0 2 → gets a dependency on libqt5gui5 only (optional|arch=!armhf !arm64 !armel)_ZN20QOpenGLFunctions_ES214versionProfileEv@Qt_5 5.2.0 3 → gets a dependency on libqt5gui5-gles only Most of these symbols are for QOpenGLFunctions* classes. I will try to get an estimate of how many package are using them a bit later. Also there are packages that build different things depending on OpenGL variant, by using qtConfig(opengles2) in their .pro files or by checking QT_OPENGL_ES macro in their C++ files. These will probably also need dual stack packages. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Hi Rohan! On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote: > [...] > > I concur here. It was correctly pointed out in another reply that by using > OpenGL we're specifically catering to software that doesn't support > GLES while making performance worse for mature applications that > do implement both OpenGL and GLES. The reality of the situation is that > the market currently favors GLES over GL on ARM SBC's, delivered with > proprietary blobs. I think a more pragmatic view of this reality would be to > deliver the best FOSS user experience that's possible with the proprietary > drivers while the open source drivers are being improved. To that extent, > by switching to GLES we improve the overall situation since OpenGL > applications can fall back to software rendering via mesa on platforms > where mesa does not support the GPU. Here I agree with Luke Kenneth Casson Leighton’s opinion [1]. I think we should aim to provide the best possible experience with the free software ecosystem. The experience with proprietary drivers should be the second priority, if priority at all. > By choosing to build Qt with GLES on ARM64, we make Debian a more > attractive platform for vendors who'd like to target ARM64 boards. We should make it attractive for vendors to release their code under a free software (DFSG) license. That way anyone would be able to hack on it and add missing support for a different OpenGL variant, if needed. That said, as Lisandro announced, we will be happy to make any decision if there is either a consensus or a TC decision about it. [1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote: > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze: > > I would still like to know if the upcoming arm64 desktop devices have > > any problems working with OpenGL ES. > > Arm64 desktop systems use Radeon or NVidia cards with same opensource > drivers as x86-64 systems. So you can check how it goes with OpenGL ES > on your amd64 desktop. I have an embedded Intel card right now :) What is the status of OpenGL ES support with these drivers? -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote: > > According to config_help.txt [1], Qt uses ES2 by default on Windows. > > It probably means that it will work fine with most desktop video cards. > > > > But as Lisandro says, such a change in Debian will break many packages > > (which are currently broken on ARM only), so we are definitely not > > considering it at this point. > > Why is it OK to break them on arm64 if it's not OK to break them on > amd64? Do you have a list of those packages? The majority of arm64 devices are mobile/embedded, which cannot be said about amd64. Of course it is bad to break packages, but leaving arm64 users with non-working Qt graphics is also not ideal. So we are trying to find a compromise solution here. We do not have a final list yet, but packages that may get broken will likely belong to one of these two groups: - Packages that build-depend on both qtbase5-dev and libglu1-mesa-dev: cgal, flightgear, fraqtive, kalgebra, kstars, ksudoku, kubrick, paraview, simplescreenrecorder, starpu, starpu-contrib, structure-synth, vtk6, vtk7 - Packages that build-depend on libqt5opengl5-desktop-dev: bino, deepin-movie-reborn, enki-aseba, fracplanet, fraqtive, freecad, krita, libconfig-model-dpkg-perl, mldemos, mm3d, openms, qwtplot3d, shelxle, soundscaperenderer, tetzle, virtualjaguar, vite, vtk7 This is not a final list yet, but should be enough to get an estimate. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote: > I do understand that there would be a lot of effort required to support OGL > and OGLES but as you have already pointed out "you are doing this already" > because OGL is provided for all platforms except armel & armhf which have > OGLES - that means you are already tracking changes for *BOTH* ecosystems. > > Having OGL & OGLES available on the same architecture would be setup > involved in creating two package streams, but once done the actual build > process is automated. Yes there are now twice as many resulting sets of > binaries for this layer, but it is reasonable to assume that functional > test of each strand can be split across the testing for all architectures > (where not automated), so the increased workload again shouldn't differ by > much (just the supporting of the automation). > > I am sure my view is nieve and a little too simplistic... Please keep in mind that not only we (the Qt maintainers) should maintain two sets of packages, but also maintainers of third party Qt libraries and applications. Even in Ubuntu where the core developers can upload any package, this setup did not work fine (they tried to maintain twin -gles packages for x86 for the Ubuntu touch port to these architectures). > As of today there are considerably more 'mobile' arm devices. I suspect > that this will continue because they are lower cost mass market products. > Full 'desktop' on arm64 has felt very close for the last few years, but > hardware isn't there just yet. > There are some quite big server SoCs out there, but the desktop & laptop > world isn't well serviced. > > [...] > > If you want to look at sheer numbers then OGLES will 'win' hands down, but > my gut tells me that long term excluding OGL from the arm64 architecture > would be the wrong decision Thanks, this information is useful! I would still like to know if the upcoming arm64 desktop devices have any problems working with OpenGL ES. Anyway, the decision we are making now is not permanent, we can always revisit it in a few years like we are now revisiting the decision to stick with desktop OpenGL. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote: > I think a better question would be: Does it improve, or disable, decent > video support for the dozens of arm64 cards in the r-pi format, such as > the arm64 based $44 rock64? [...] As far as I know Raspberry Pi 3 and similar devices work fine with OpenGL ES. E.g. Raspbian does not override our choice to build qtbase with OpenGL ES on armhf. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Upcoming Qt switch to OpenGL ES on arm64
On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote: > At least mesa drivers can be used for desktop GL or GLESv2 just fine, > AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all > architectures, to stop the special-casing madness, instead of making it > spread? :) According to config_help.txt [1], Qt uses ES2 by default on Windows. It probably means that it will work fine with most desktop video cards. But as Lisandro says, such a change in Debian will break many packages (which are currently broken on ARM only), so we are definitely not considering it at this point. [1]: https://code.qt.io/cgit/qt/qtbase.git/tree/config_help.txt#n271 -- Dmitry Shachnev signature.asc Description: PGP signature
Upcoming Qt switch to OpenGL ES on arm64
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add arm64
to the list of architectures where OpenGL ES is used.
We want your feedback! If you are using an arm64 device or board with Qt,
please let us know your opinion about this change, by replying to this mail
or to [1], and describe your use case.
So far we are going to make this change starting with the Qt 5.11.3 packages.
In case you already want to test it, the updated qtbase package is available
in experimental [2]. However the reverse dependencies are not yet rebuilt.
This change will affect packages using Qt Gui [3], Qt Widgets [4], Qt Quick
and some other modules. It will not affect packages using the deprecated Qt
OpenGL module because it loads the OpenGL library at runtime.
The best way to check whether some package needs changes is checking Ubuntu
[5], which has been building Qt with OpenGL ES on arm64 since version 16.10
(yakkety) [6].
We will send a new mail with DD-list of packages that we detect to be affected
a bit later.
There are some packages that are not compatible with OpenGL ES. For example,
packages using libglu and Qt simultaneously will most likely have to drop
their arm64 binaries (like they already have no armel or arm64 binaries).
An example of such package is qwtplot3d.
Also note that as this change breaks ABI on arm64, we are renaming libqt5gui5
to libqt5gui5a, which will need binNMUs of all reverse dependencies. The list
of all such dependencies is available here [7]. This will happen together with
the Qt 5.11.3 transition.
Please Cc me or pkg-kde-talk on reply.
[1]: https://bugs.debian.org/881333
[2]: https://tracker.debian.org/news/1004843/
[3]: https://doc.qt.io/qt-5/qtgui-index.html#opengl-and-opengl-es-integration
[4]: https://doc.qt.io/qt-5/qopenglwidget.html
[5]: https://launchpad.net/ubuntu/+source/${SOURCE_PACKAGE_NAME},
or the “ubuntu patches” link in the right panel of tracker.debian.org
[6]: https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/197063f08928ac9c
[7]: https://perezmeyer.com.ar/ben/qtbase.html
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#901166: ITP: python-markdown-math -- Math extension for Python-Markdown
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: python-markdown-math Version : 0.5 Upstream Author : Dmitry Shachnev * URL : https://github.com/mitya57/python-markdown-math * License : BSD-3-clause Programming Lang: Python Description : Math extension for Python-Markdown This package extends Python-Markdown with support for displaying math formulas using MathJax or AsciiMath. I need it for packaging the latest version of PyMarkups. It will be maintained under Debian Python Modules Team umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#901165: ITP: mkdocs-nature -- Nature theme from Sphinx adapted for MkDocs
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: mkdocs-nature Version : 0.2.1 Upstream Author : Waylan Limberg * URL : http://waylan.limberg.name/mkdocs-nature/ * License : BSD-2-clause Programming Lang: Python, CSS Description : Nature theme from Sphinx adapted for MkDocs This package provides the Nature theme for MkDocs documentation generator. I need it for packaging the latest version of Python-Markdown. I will be maintaining it in https://salsa.debian.org/debian/mkdocs-nature. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#869227: ITP: qtwebview-opensource-src -- display web content in a QML application
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: qtwebview-opensource-src Version : 5.9.1 Upstream Author : Qt Project * URL : http://doc.qt.io/qt-5/qtwebview-index.html * License : LGPL-3 or GPL-2 Programming Lang: C++ Description : display web content in a QML application Qt WebView provides a way to display web content in a QML application in a cross-platform way. On mobile platforms it uses native APIs where possible; on Debian it uses Qt WebEngine. This package will be maintained under the Debian Qt/KDE team umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#867763: ITP: sphinxcontrib-websupport -- Python API to integrate Sphinx documentation into Web applications
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev Control: block 866789 by -1 * Package name: sphinxcontrib-websupport Version : 1.0.1 Upstream Author : Sphinx developers * URL : https://github.com/sphinx-doc/sphinxcontrib-websupport * License : BSD-2-clause Programming Lang: Python Description : Python API to integrate Sphinx documentation into Web applications This project provides a means for integrating Sphinx-based documentation into web applications. It adds support for comments, storage (based on SQLAlchemy), and search engines (whoosh and xapian). This package has been split out of Sphinx, and is a dependency for Sphinx 1.6. It will be maintained under Debian Python Modules Team umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#822697: general: qt5 apps in gnome do not use the gtk style as they should
Control: reassign -1 libqt5widgets5 5.5.1+dfsg-16 Control: tags -1 moreinfo Hi Miguel, On Tue, Apr 26, 2016 at 06:20:10PM +0100, Miguel Negrao wrote: > Qt5 apps (e.g. qmapshack) do not use the gtk style as should be the default. > Because of this they look a bit more ugly, for instance the buttons to close > panes have a black X instead of a white X on red background. Launching the qt5 > binary with '-style=gtk' gives the right look, but the system should be > configured such that this is not necessary. This most likely means that Qt does not recognize your desktop as needing GTK+ integration. Can you please check what is the value of XDG_CURRENT_DESKTOP environment variable on your system? Also, please keep in mind that the GTK+ style will be removed in Qt 5.7, and the recommended alternative is using custom themes like Adwaita-Qt. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#819913: ITP: imagesize_py -- Getting image size from png/jpeg/jpeg2000/gif file
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: imagesize_py Version : 0.7.0 Upstream Author : Yoshiki Shibukawa * URL : https://github.com/shibukawa/imagesize_py * License : MIT Programming Lang: Python Description : Getting image size from png/jpeg/jpeg2000/gif file This small module parses image header and returns width and height of the image. Supported formats are: PNG/JPEG/JPEG2000/GIF. It is needed for the latest Sphinx release, 1.4. This package will be maintained under DPMT umbrella. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#813291: ITP: keyrings.alt -- Alternate keyring backend implementations for use with python-keyring
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: keyrings.alt Version : 1.1 Upstream Author : Jason R. Coombs * URL : https://github.com/jaraco/keyrings.alt * License : MIT Programming Lang: Python Description : Alternate keyring backend implementations for use with python-keyring Python-Keyring is a module that provides a cross-platform interface to store passwords, and has multiple backends. Recently that package has been split into two parts: base (python-keyring) which contains only recommended secure backends, and keyrings.alt which contains all the other backends. This ITP is for the latter package. I am going to make python-keyring recommend keyrings.alt, with a goal to downgrade that to Suggests in the future. This package will be maintained under DPMT umbrella. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#758721: ITP: gnome-flashback -- Classic GNOME session
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: gnome-flashback Version : 3.10.0 Upstream Author : Alberts Muktupāvels * URL : http://git.gnome.org/browse/gnome-flashback * License : Mostly GPL-3+ Programming Lang: C Description : Short package description GNOME Flashback project provides a classic GNOME environment using GNOME Panel and Metacity window manager. This package will contain the session files (used to be shipped in gnome-panel source package) and a helper gnome-flashback binary, which draws the desktop background and provides Shutdown / End Session dialog. Note that there has not yet been an official release of the new source, but I am going to package a Git snapshot in experimental. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Re: Math Fonts for Iceweasel and MathJax
Hi Fabian, On Thu, Dec 20, 2012 at 5:01 PM, Fabian Greffrath wrote: >> - fonts-mathjax: contains OTF, SVG and WOFF fonts (installed in the >> previous location, with a /usr/share/fonts/opentype/mathjax → >> /usr/share/javascript/mathjax/fonts/HTML-CSS/TeX/otf symlink); > > > Did you symlink the directory or its contents? The directory. I could make the link reverse (←), but that would require adding a pre-inst script as dpkg (AFAIC) doesn't allow replacing a directory with a symlink. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakimphu8whih2h8wmqrzmsbrkymdlgkur8cdcfyodb4rdzl...@mail.gmail.com
Re: Math Fonts for Iceweasel and MathJax
[Please CC me in your replies as I'm not subscribed to debian-devel@]. Now I've added two new packages to mathjax source (see my packaging branch at [1]): - fonts-mathjax: contains OTF, SVG and WOFF fonts (installed in the previous location, with a /usr/share/fonts/opentype/mathjax → /usr/share/javascript/mathjax/fonts/HTML-CSS/TeX/otf symlink); - fonts-mathjax-extras: contains PNG and EOT fonts (installed in the previous location). I hope this will suit everybody, but please mention if you don't like this scheme. [1]: http://anonscm.debian.org/gitweb/?p=pkg-javascript/mathjax.git -- Dmitry Shachnev On Tue, Dec 18, 2012 at 6:09 PM, Frédéric WANG wrote: > Thank you Dmitry. Yes, I don't think it's a problem if you keep the current > path and that may probably be best for MathJax users to have the usual path. > However, if that's not already the case, I suspect your installation script > should use fontconfig or something to make the other programs aware of the > MathJax fonts. That said I am neither a font expert nor a debian maintainer, > so I guess other Debian people could know better what is the appropriate way > to package these fonts. But in any cases, a separate package sounds the > right way to do so. > > > On 18/12/2012 14:54, Dmitry Shachnev wrote: >> >> Hi Frédéric, >> >> I can split the fonts into a separate package. Will it be OK if I keep >> the current path (/usr/share/javascript/mathjax/fonts/), or should I >> change it to something else to make it possible to load the fonts from >> other applications? >> >> -- >> Dmitry Shachnev > > > -- > Frédéric Wang > maths-informatique-jeux.com/blog/frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakimphw6gtuemgq25pzmhy6qonrxnlmralggppo4ncz0vn-...@mail.gmail.com
Re: MATE Desktop Environment in Debian
I agree with Josselin here. There is no point in forking gconf and other libraries. Even worse, this will increase the incompatibility between different desktops. For example, an app making use of "gconftool-2" will not work when there's "mateconftool-2" in the system instead. If you want to fix a bug in GNOME libraries, you should propose a patch to their bugzilla, they will be happy to accept it. Also, we try to remove existing packages that use deprecated libraries (like libgnome* and libbonobo*), and I think it's not good at all to add new packages relying on those libraries. -- Dmitry Shachnev (Debian Maintainer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1343127220.7568.5.camel@eeepc
Re: MATE Desktop Environment in Debian
I agree with Josselin here. There is no point in forking gconf and other libraries. Even worse, this will increase the incompatibility between different desktops. For example, an app making use of "gconftool-2" will not work when there's "mateconftool-2" in the system instead. If you want to fix a bug in GNOME libraries, you should propose a patch to their bugzilla, they will be happy to accept it. Also, we try to remove existing packages that use deprecated libraries (like libgnome* and libbonobo*), and I think it's not good at all to add new packages relying on those libraries. -- Dmitry Shachnev (Debian Maintainer) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1342780899.5199.17.camel@eeepc
