Bug#1037927: ITP: fuse -- bazil.org/fuse - With macOS support and its own import path so replace directives aren't necessary
On Wed, 14 Jun 2023, Félix Sipma wrote: * Package name: fuse There's already a package named fuse in Debian: https://tracker.debian.org/pkg/fuse Regards, Scott
Bug#919903: ITP: wxwidgets3.2 -- wxWidgets Cross-platform C++ GUI toolkit
On 2022-08-27 03:20, Andrea Pappacoda wrote: Control: tags -1 - wontfix Hi, I've just built wxwidgets3.2 from the salsa [repo], but it seems that the wx-common package isn't being built. Is this intentional? Yes, because wx-common is currently being built by wxwidgets3.0 until we get wxwidgets3.2 through NEW and into the archive. I needed wxWidgets 3.2 because I'm packaging Cemu (#1018037), and it requires the latest wxWidgets version. Also, why was this packaged in a new repo? Because I wanted to get rid of some cruft from the old repo and also switch to a git-buildpackage layout. Scott
Bug#840032: Adopting execnet
On Tue, 11 Sep 2018, Scott Talbert wrote: I don't mind adopting execnet as pytest-xdist uses it. Do you mind granting me DM rights as you did for pytest-xdist? BTW, I can take apipkg too. Scott
Bug#840032: Adopting execnet
Hi Daniel, I don't mind adopting execnet as pytest-xdist uses it. Do you mind granting me DM rights as you did for pytest-xdist? Thanks, Scott
Bug#890091: ITP: pytest-forked -- py.test plugin for running tests in isolated forked subprocesses
Package: wnpp Severity: wishlist Owner: Scott Talbert <s...@techie.net> * Package name: pytest-forked Version : 0.2 Upstream Author : pytest-dev <pytest-...@python.org> * URL : https://pypi.python.org/pypi/pytest-forked * License : MIT Programming Lang: Python Description : py.test plugin for running tests in isolated forked subprocesses The pytest-forked plugin extends py.test by adding an option to run tests in isolated forked subprocesses. This is useful if you have tests involving C or C++ libraries that might crash the process. To use the plugin, simply use the --forked argument when invoking py.test. Needed as a dependency of pytest-xdist. Plan to maintain as part of DPMT.
Bug#888554: ITP: wxpython4.0 -- Python interface to the wxWidgets Cross-platform C++ GUI toolkit, Phoenix version
Package: wnpp Severity: wishlist Owner: Scott Talbert <s...@techie.net> * Package name: wxpython4.0 Version : 4.0.0 Upstream Author : Robin Dunn <someb...@example.org> * URL : https://www.wxpython.org/ * License : wxWindows Library License Programming Lang: Python Description : Python interface to the wxWidgets Cross-platform C++ GUI toolkit, Phoenix version wxWidgets (formerly known as wxWindows) is a class library for C++ providing GUI components and other facilities on several popular platforms (and some unpopular ones as well). . This package provides a Python interface to the wxGTK library and the wxPython runtime support libraries. This is the "Phoenix" implementation which now supports Python 3.
Bug#870844: Adopting pytest-xdist
Hi, I'm willing to adopt pytest-xdist. Scott
Bug#782970: [tryton-debian] python-profitbricks-client: Please use a maintained soap library instead of deprecated python-suds.
On Sat, 22 Aug 2015, Mathias Behrle wrote: * Scott Talbert: Re: [tryton-debian] python-profitbricks-client: Please use a maintained soap library instead of deprecated python-suds. (Fri, 21 Aug 2015 20:10:24 -0400 (EDT)): On Fri, 21 Aug 2015, Mathias Behrle wrote: I would much prefer to use suds-jurko as drop-in replacement for our current suds, because * suds-jurko is a fork that does not break the API There may be some probability for this, but Jurko himself didn't give the guarantee, that the changes already done didn't affect the API. Do you want to provide this guarantee? * the original suds upstream is dead * the original suds could reclaim the namespace if upstream was becoming active again * rdepends don't have to change anything rdepends should use the new upstream explicitly (see above) instead of perhaps suddenly failing because of a more or less inadvertised drop-in. IMO it makes no sense to rename the Debian binary package to python-suds-jurko when you still run import suds instead of import suds_jurko. It is not renaming a package, but indeed a new package. Just like the project on Pypi is different from the still existing suds. After looking again to the current state of suds-jurko (which is no more fully API compatible), the result of the conversation at DebConf today between Benjamin and me is: Are you confirming that suds-jurko is definitely not API compatible with suds, or are you just stating that there is uncertainty whether it is API compatible? Indeed I recently stumbled about an incompatibility. This one refers to a logging method and is not a big deal, but so I can confirm. Just out of curiosity, what was the incompatibility? Scott
Bug#782970: [tryton-debian] python-profitbricks-client: Please use a maintained soap library instead of deprecated python-suds.
On Fri, 21 Aug 2015, Mathias Behrle wrote: I would much prefer to use suds-jurko as drop-in replacement for our current suds, because * suds-jurko is a fork that does not break the API There may be some probability for this, but Jurko himself didn't give the guarantee, that the changes already done didn't affect the API. Do you want to provide this guarantee? * the original suds upstream is dead * the original suds could reclaim the namespace if upstream was becoming active again * rdepends don't have to change anything rdepends should use the new upstream explicitly (see above) instead of perhaps suddenly failing because of a more or less inadvertised drop-in. IMO it makes no sense to rename the Debian binary package to python-suds-jurko when you still run import suds instead of import suds_jurko. It is not renaming a package, but indeed a new package. Just like the project on Pypi is different from the still existing suds. After looking again to the current state of suds-jurko (which is no more fully API compatible), the result of the conversation at DebConf today between Benjamin and me is: Are you confirming that suds-jurko is definitely not API compatible with suds, or are you just stating that there is uncertainty whether it is API compatible? Scott
Bug#782970: Bug#783029: Bug#788087: python-profitbricks-client: Please use a maintained soap library instead of deprecated python-suds.
On Wed, 8 Jul 2015, Mathias Behrle wrote: Instead of porting python-profitbricks-client, I would prefer to take over the maintenance of suds for at least the stretch release and follow the suds-jurko releases. Some time ago, I already made sure that python-profitbricks-client works with the Python3 version of suds-jurko. What do you think? Basically I can not add much to #783029. Indeed there is some recent action from the maintainer side. All efforts to use suds-jurko as a drop-in replacement (or separate package by Lionel) were done, but neither me (nor Lionel who wanted to do the same as you want to do now) finally wanted to turn into a definite upstream for suds-jurko. For me things are quite unchanged, but perhaps you are lucky to be able to revive the contact with Jurko so you can get some feedback about his future plans. Finally I only can recommend to evaluate the porting effort of python-profitbricks-client (and possibly other rdepends of suds) vs. the maintenance effort of suds-jurko. Bug reports filed against rdepends of suds are available at [0]. The result of above said evaluation could of course be influenced by the porting effort needed by other rdepends. Basically they/we all will be thankful, if there is a maintained suds alternative available. Looking at those bug reports: * 2 just removed the suggestion of python-suds * The maintainer of congruity (#788082) responded that porting to pysimplesoap would not be an easy effort * All other maintainers haven't responded yet Mathias, may become co-maintainer or adopt python-suds? I wait for your go before preparing suds-jurko with Python 3 support. Hi Benjamin, I would prefer the following way: 1) Jurko, the maintainer of suds-jurko, was offered, that his package could take over the name from original suds on Pypi. He didn't make use of this offer so far. That would have been a good starting point to use suds-jurko (then suds) as a drop-in for current suds. As this is not the case I would indeed prefer to keep the projects resp. packages separate. As the package must go through NEW anyway for Python 3 support, this is the cleaner way to get suds-jurko into the archive. Could you please coordinate with Lionel, who prepared already an initial separate suds-jurko package [0]? Please let me know ASAP to inform Rdepends about the new package to prevent evtl. unneeded work on their side (or do that yourself). 2) Please add Provides and Conflicts with python-suds (as done by Lionel). As soon as suds-jurko will hit unstable I will add the Conflicts to python-suds and change the package description to hint to your package. 3) Rdpends of python-suds will be informed to update their Depends to python*-suds-jurko. 4) python-suds will be removed from the archive before the release of stretch. Is this OK for you? I would much prefer to use suds-jurko as drop-in replacement for our current suds, because * suds-jurko is a fork that does not break the API There may be some probability for this, but Jurko himself didn't give the guarantee, that the changes already done didn't affect the API. Do you want to provide this guarantee? * the original suds upstream is dead * the original suds could reclaim the namespace if upstream was becoming active again * rdepends don't have to change anything rdepends should use the new upstream explicitly (see above) instead of perhaps suddenly failing because of a more or less inadvertised drop-in. IMO it makes no sense to rename the Debian binary package to python-suds-jurko when you still run import suds instead of import suds_jurko. It is not renaming a package, but indeed a new package. Just like the project on Pypi is different from the still existing suds. Hi Benjamin, I support getting suds-jurko into Debian as well. I am happy to help maintain the package if you would like help. Thanks, Scott -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1507092117090.11...@bear.techie.net
Bug#724568: (no subject)
RFS bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725749 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lrh.2.03.1310072006430.17...@techie.net
Bug#724568: ITP: hidapi -- Library for communicating for USB and Bluetooth HID devices
Thibaut Girka t...@sitedethib.com wrote: On Tue, Sep 24, 2013 at 11:18:15PM -0400, Scott Talbert wrote: Package: wnpp Severity: wishlist Owner: Scott Talbert s...@techie.net * Package name: hidapi Version : 0.7.0 Upstream Author : Alan Ott a...@signal11.us * URL : http://www.signal11.us/oss/hidapi/ * License : GPLv3 or BSD Programming Lang: C Description : Library for communicating for USB and Bluetooth HID devices HIDAPI is a multi-platform library which allows an application to interface with USB and Bluetooth HID-class devices on Windows, Linux, FreeBSD, and Mac OS X. On Linux, either the hidraw or the libusb back-end can be used. There are trade-offs and the functionality supported is slightly different. Hi, did you start working on it? If so, is it publicly available somewhere? I've started a package for my personal use, but as I wasn't sure it would be useful to others and that I've got increasingly limited free time, I haven't filed an ITP. Anyway, I've attached my current debian.tar.gz if it can be of any help. Hi, I have not started on it. Thanks for sending your package - I will use that as a starting point. Scott -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/001ba2d3-9576-4c59-8d9e-a4c07cdce...@email.android.com
Bug#724568: ITP: hidapi -- Library for communicating for USB and Bluetooth HID devices
Package: wnpp Severity: wishlist Owner: Scott Talbert s...@techie.net * Package name: hidapi Version : 0.7.0 Upstream Author : Alan Ott a...@signal11.us * URL : http://www.signal11.us/oss/hidapi/ * License : GPLv3 or BSD Programming Lang: C Description : Library for communicating for USB and Bluetooth HID devices HIDAPI is a multi-platform library which allows an application to interface with USB and Bluetooth HID-class devices on Windows, Linux, FreeBSD, and Mac OS X. On Linux, either the hidraw or the libusb back-end can be used. There are trade-offs and the functionality supported is slightly different. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130925031815.2085.88406.report...@debian-unstable.techie.net
