Re: Moving default branch after project creation
On 2024-08-08 08:42, Carsten Schoenert wrote: > $ gbp import-orig --verbose --sign-tags --pristine-tar > --upstream-branch=upstream --debian-branch=debian/master > ~/Downloads/psrecord-1.4.tar.gz I suggest to use `upstream/latest` as upstream branch. It spares you separating upstream/latest, upstream/master, upstream/whatever later. Cheers
Bug#1077908: ITP: python-thumbhash -- compact representation of an image placeholder
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-thumbhash Version : 0.1.2 Upstream Author : Justin * URL : https://github.com/justinforlenza/thumbhash-py/ * License : MIT Programming Lang: Python Description : compact representation of an image placeholder This is a Python port of the thumbhash encoder by Evan Wallace. . The library only handles the conversion of images to hashes, not the reverse.
Re: Policy Change Proposal: Running the upstream test suite
Quoting PICCA Frederic-Emmanuel : It install by default the build dependencies. which is not what peoples are doing when they install the packages. It should be possible to define the autopkgtest dependencies. This way we could catch missing dependencies in python- dependencies. Is it possible ? I believe (didn't check so many packages), in most cases installing the build dependencies is the better option: 1. There might be testing frameworks to install as b-d, but not as Depend. 2. Many unit test suites check various variants and optional behaviour, that might be separated in different binary packages (think of myapp-postgres and myapp-mariadb, etc.) Maybe as an option for some packages? Or a different kind of test, running on top of piuparts?
Re: Status of sqlalchemy
Hi Piotr, On 2024-04-15 15:07, Piotr Ożarowski wrote: > sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and > 3.12) somewhere in pysqlite: ... > I will upload to unstable once I figure that one out Any news on that? Thank you! (I'm not sure, if I can help with that, unfortunately.) Cheers
Re: Status of pymodbus (was: Status of sqlalchemy)
Hi Alexandre, I pushed my changes to debian/master. If you have time to work on pymodbus (e.g. update disable-failing-unittests.patch), please go on. I probably can't work on that this week. Cheers
Re: Status of pymodbus (was: Status of sqlalchemy)
Quoting Alexandre Detiste : I ll check back home, but it's most likely I was waiting for SQLAlchemy 2.xx. Good! I know for share that one package does wait for SA 2.xx but can t remember which one. It looksk like all but one of the debian/patches are obsolete now? It seems, that *two* patches need to stay, but need work: 1. privacy-breach-fixes.patch (I updated this, can push later) 2. disable-failing-unittests.patch (needs more work, don't hold your breath) There are also two (?) new build-depends. Again, I can push later. debian/rules needs a minor PYTHONPATH fix. Will push when back home ;-) Cheers
Status of pymodbus (was: Status of sqlalchemy)
On 2024-04-15 11:38, Alexandre Detiste wrote: > Le lun. 15 avr. 2024 à 11:20, Thomas Goirand a écrit : >> The rest of: >> - pymodbus >> >> I don't even know what they do. > > Life is better when one does not have to deal with modbus :-) Yes! > This package is outdated and need a refresh. As I see, you already pushed a new upstream to git in January/February, but did not yet upload the package. Are there any blockers? It looks like all but one of the debian/patches are obsolete now?
Re: Status of sqlalchemy
Quoting Piotr Ożarowski : sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and 3.12) somewhere in pysqlite: ... I will upload to unstable once I figure that one out Perfect! I prefer not to mess with the package, if I don't have to ;-) Thanks, Piotr!
Re: Status of sqlalchemy
Quoting Thomas Goirand : The rest of: - pymodbus - sqlalchemy-utc - wtforms-alchemy I don't even know what they do. All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid and we move on... I'll check, if I can update pymodbus, which is some versions behind upstream. Maybe that already fixes things. I don't know about the other two: I feel uneasy to break them, but we need SQLAlchemy 2.x anyway, looks like 1.x is not supported anymore. If nobody objects (or is faster than me), I'll upload SQLAlchemy 2.x to unstable in a couple of days or weeks. No hurry from my side. Cheers
Re: Status of sqlalchemy
Hi, are there any news regarding the status of sqlalchemy? I'm curious, because the next version of gajim will depend on sqlalchemy >= 2, which is only in experimental right now. Cheers
Re: morph's abandoned packages (list)
On 2024-03-15 14:21, Alexandre Detiste wrote: > I would pick-up matplotlib I guess, I have some special connection to it, ... > Help is appreciated, I already cherry picked some commits from Ciel's PR. I *might* help on this, because we use matplotlib at $DAYJOB, but can't promise much, as my workload is already pretty high. Cheers
Re: Suggesting change in DPT policy
On 2024-02-27 15:15, Thomas Goirand wrote: > Though indeed, I don't > think it's reasonable to have a package in the team, but with strong > ownership. I believe that we should either have a package in the team, > or not. Period. I'm in favour of that change, too, but I can live with the current state as well. All my packages are team owned, and I'm mere uploader, anyway. Cheers
Bug#1063940: ITP: python-term-image -- Display images in the terminal with Python
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org Package Name: python-term-image Version: v0.7.1 Upstream Author: Toluwaleke Ogundipe License: MIT Programming Lang: Python 3 Homepage: https://github.com/AnonymouX47/term-image Description: Display images in the terminal with Python term-image is a library and program to display images on compatible terminals. . Features: - Multiple image formats (basically all formats supported by PIL.Image.open() - Multiple image source types: PIL image instance, local file, URL - Multiple image render styles (with automatic support detection) - Support for multiple terminal graphics protocols: Kitty, iTerm2 - Exposes various features of the protocols - Transparency support (with multiple options) - Animated image support (including transparent ones) - Multiple formats: GIF, WEBP, APNG (and possibly more) - Fully controllable iteration over rendered frames of animated images - Image animation with multiple parameters - Integration into various TUI / terminal-based output libraries. - Terminal size awareness - Automatic and manual image sizing - Horizontal and vertical alignment - Automatic and manual font ratio adjustment (to preserve image aspect ratio) This is a new, optional dependency (Recommends) of libervia-backend.
Bug#1063815: ITP: vapid -- Simple VAPID header generation library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org Package Name: vapid / python3-py-vapid Version: 1.8.2 Upstream Author: JR Conlin License: MPL2 Programming Lang: Python 3 Homepage: https://github.com/web-push-libs/vapid Description: Simple VAPID header generation library This minimal library contains the minimal set of functions you need to generate a VAPID key set and get the headers you'll need to sign a WebPush subscription update.
Bug#1063814: ITP: encrypted-content-encoding -- Encrypted Content-Encoding for HTTP
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org Package Name: encrypted-content-encoding / python3-http-ece Version: v1.2.0 Upstream Author: Martin Thomson License: MIT Programming Lang: Python 3 Homepage: https://github.com/web-push-libs/encrypted-content-encoding Description: Encrypted Content-Encoding for HTTP This library implements HTTP ECE in accordance with RFC 8188. It is needed e.g. for WebPush.
Bug#1057361: ITP: pickle-secure -- wrapper around pickle that creates encrypted pickles
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org Control: blocks 1019277 by -1 Package Name: pickle-secure Version: 0.99.9 Upstream Author: Stephanos Kuma License: LGPL-3 Programming Lang: Python 3 Description: wrapper around pickle that creates encrypted pickles pickle-secure offers a similar API as the built-in pickle. This is a (build) dependency for Slidge.
Re: Updating python3-xlrd for pandas 1.5 compatibility
On 2023-02-22 23:12, Diane Trout wrote: > | visidata | none | Build-Depends | There seems to be no versioned depends or similar in the code. Should be safe, but in doubt ask Anja (upstream). Cheers
Bug#1021759: ITP: py-rnp -- Python bindings for librnp
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: py-rnp Version : 0.1.0 Upstream Author : Daniel Wyatt * URL or Web page : https://github.com/rnpgp/py-rnp * License : (under investigation) Description : Intent to Package [ITP] Python bindings for librnp. RNP is a set of cross-platform tools implementing OpenPGP (RFC 4880) and related standards.
Bug#1021569: RFP: ttconv -- library and tool for converting timed text or subtitle formats
Package: wnpp Severity: wishlist * Package name: ttconv Version : 1.0.5 Upstream Author : Pierre-Anthony Lemieux * URL or Web page : https://github.com/sandflow/ttconv * License : BSD 2-Clause Description : library and tool for converting timed text or subtitle formats ttconv is a library and command line application written in pure Python for converting between timed text formats used in the presentations of captions, subtitles, karaoke, etc. Input formats: TTML / IMSC, SCC / CEA 608, EBU STL, SRT Output formats: IMSC / TTML, WebVTT, SRT
Bug#1019492: RFP: python-aiosignald -- Python bindings for signald
Package: wnpp Severity: wishlist * Package name: python-aiosignald Version : v0.3.1 Upstream Author : Nicolas Cedilnik * URL or Web page : https://git.sr.ht/~nicoco/aiosignald * License : AGPL-3+ Description : Python bindings for signald > Interact with the signal messaging network in python with sweet, sweet > autocompletion. Most of the code is generated by the generate.py > script that uses the schema available at > https://signald.org/protocol.json. No 3rd party dep, just the python > standard lib.
Re: Desire to join
On 2022-08-03 19:57, Felix Delattre wrote: > So far I have contributed to Debian: And Felix is also my co-upstream of https://tracker.debian.org/sms4you :-)
Bug#1008738: ITP: python-cobs -- Consistent Overhead Byte Stuffing for Python
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-cobs Version : v1.2.0 Upstream Author : Craig McQueen * URL : https://github.com/cmcqueen/cobs-python/ * License : MIT Programming Lang: Python Description : Consistent Overhead Byte Stuffing for Python The cobs package is provided, which contains modules containing functions for encoding and decoding according to COBS methods. I intent to maintain this package under the umbrella of the Debian Python Team.
Request to join the Debian Python Team
Hi all, I would like to join the Debian Python Team. My salsa handle is "mguenther" (the account is still pending approval). The reason why I would like to join the team is to maintain the "pass-git-helper" package, which is currently up for adoption [1]. Jochen Sprickerhof (jspri...@debian.org) will transfer the package to the DPT and sponsor me. I have read the policy [2] and accept it. Best wishes, Martin [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007004 [2]: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst OpenPGP_signature Description: OpenPGP digital signature
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
On 2021-06-26 02:04, Paul Wise wrote: > I would like to see #2 split into two separate tarballs, one for the > exact copy of the git tree and one containing the data about the other > tarball. Then use dpkg-source v3 secondary tarballs to add the data > about the git repo to the Debian source package. IIRC, last time I tried multiple tarballs, I got stuck with pristine-tar. Not sure, if I didn't find out how to commit or if the problem was with checkout, though. Do you happen to know, if this is an issue? PS: Just for the record: I'm always(?) using upstream sources from git, not PyPi, because the latter typically are missing unit tests, which we want to run in Debian.
Re: Remove trac from Debian 11?
On 2021-05-10 14:00, Andrius Merkys wrote: > I do not think that slowing down of development is reason serious enough > to remove a package which is otherwise fine. Or are there other reasons > that I am not aware of? I don't have a problem with slow development, but the current version is probably not good enough to maintain it for some years. I'm optimistic, that in some months or so 1.6.x will be released, which should be fine. I'm planning to backport it to Debian 11, so that users still can install trac easily.
Remove trac from Debian 11?
Dears, trac is a long-time Debian package, uploaded first by Jesus Climent in 2004. I like the traditional look of Trac and its climate-friendly resource usage :-) Now, while Trac is still maintained upstream and has been ported to Python 3 recently, development slowed down since long and the current 1.5.x release series is not yet "there". I wonder, whether the package should be part of Debian 11, or better miss one stable release and have it in better shape for Debian 12. If nobody objects, I'll file a bug to keep it out of Debian 11. Comments welcome! Cheers
Re: Python package situation
On 2021-02-17 02:13, Andrey Rahmatullin wrote: > Are you asking about testing or stable? Because for stable the "packages > are either outdated or do not exist" situation is somewhat expected and > testing is not that interesting case, though even in testing we may have a > lot of outdated packages. At work, we are using stable with backports. Once in a while we make a local package or local backport, too, and put it in our local (reprepro driven) repo. Very often, we can just accept the version in Debian, even if it is not the latest one. > Surely you use only a subset of modules while other people may need a > different subset, and ability to make and upload new or updated packages, > unavailable for most Debian Python users, is definitely helpful. Yes, having upload rights to Debian, incl. backports, is very helpful and I was not implying that it were the same situation for those without that priviledge :-) But at least people on this ML either have that possibility or know how to file RFPs/ITPs or just ask the right people. But that option is less attractive, if the work is far too much, i.e. either too many packages involved or very tricky packages - for technical or other reasons. That's why I'm curious: Maybe the missing packages are the same for multiple people and we can solve the problem?
Python package situation
On 2021-02-16 10:17, Bastian Venthur wrote: > I *wish* I could > just install everything via the Debian Packaging System, but the reality for > most relevant Python packages is very different: packages are either > outdated or do not exist in Debian Are you talking about many packages? Or only some, that are difficult to package? Can you give an example? At my job, we were always able to stay with Debian packages, or I just packaged the missing pieces, but maybe our use case is not that advanced. I believe, that we don't have much of the Django ecosystem packaged and many aio* packages seem to be missing... Cheers
Re: upstream python concerns, python3-full package for bullseye
On 2021-02-12 10:16, Thomas Goirand wrote: > I mostly agree to add a metapackage. I just don't agree with the choice > of package name. It makes our user believe that Python isn't "full" > without it, and they then may install it when they don't need it to > consume whatever is packaged in Debian. Reality is different. I agree with your technical point of view. Friends don't let friends use pip and I banned its use at work. I don't care about having the package or not and how it were named, as long as it remains easy to not have it. Cheers
Re: python3-(py)crypto(dome)?
On 2020-12-05 19:51, Andrey Rahmatullin wrote: > On Sat, Dec 05, 2020 at 02:43:44PM +0100, Martin wrote: > > Package wokkel has changed the dependency from python3-crypto to > > python3-cryptodome, leading to #975748 and #975770. > The changelog entry says "Switch to python3-pycryptodome" but the control > field says "python3-cryptodome". This is a bug in python3-wokkel, > unrelated to the initial question here. Related in the sense: If python3-pycryptodome would provide python3-crypto, the old dependency were correct. If python3-pycryptodome would be renamed to python3-cryptodome, the current dependency were correct. The fix in wokkel should not lead to a problem after the next upload of python3-pycryptodome. Anyway, if nobody objects, I just upload the fixed wokkel. Cheers
python3-(py)crypto(dome)?
Dears, I'm a little confused about what the correct name for the binary package python3-pycryptodome should or will be. Because https://bugs.debian.org/891619 talks about renaming it and/or providing python3-crypto. Package wokkel has changed the dependency from python3-crypto to python3-cryptodome, leading to #975748 and #975770. For now, I would upload wokkel with changed dependency, from python3-cryptodome to python3-pycryptodome. Any objections? Cheers
Re: Granting `Janitor` direct access to our teams repos
On 2020-07-27 20:18, Sandro Tosi wrote: > So: let's just make that automatic? Thoughts? Yes.
Re: packaging DiscoDOS - a cli tool for vinyl DJs
On 2020-05-15 17:43, jojo wrote: > I'd like to join the list because I think my software is a valuable addition > to the debian universe, my ultimate goal would be to bring it into Ubuntu > Studio because it is music-related. Cool! Sounds like a very interesting program, indeed!
Remove or update pyfeed and xmlelements
Hi Matteo, hi Thomas, the new version of salutatoi does not need python-feed and python-xe anymore. AFAIK, there are not other dependencies on them. Maybe you would like to ask for removal? If not, remember to update them to Python 3 (currently supported only in experimental, but still with Python 2 versions). Cheers
Re: Non-migration of cssutils
Quoting Mattia Rizzolo : Given that the whole stack of packages is scheduled to get out on 2020-02-16, it's more likely that everything will be removed, and then cssutils will migrate back (and with it everything that will be suitable to migrate back into testing) at the next britney run. That's fine for me! Thanks for the explanation!
Re: Non-migration of cssutils
Quoting Mattia Rizzolo : I reckon the way forward is to fix those two FTBFS in calibre. If calibre gets removed from testing on 2020-02-16, the reason for non-migration of cssutils and removing depending packages from testing, e.g. gajim, vanishes. Will this work out due to britneys wisdom? Or should calibre better removed from testing before 2020-02-16, if problems are not fixed until then?
Non-migration of cssutils
Hi, at https://tracker.debian.org/pkg/cssutils I don't see, why the package does not migrate. Some package depend on cssutils and will be removed from testing soon... Any idea what's wrong with cssutils? TIA & Cheers
Re: Future of Trac in Debian
Quoting Sandro Tosi : So Jan 1 arrived, what do you think we should do? i didnt see any progress on the port to python3 upstream; should we start filing RM for trac extensions/plugins and once they are gone, RM src:trac? I don't expect a Python 3 version of Trac before a year from now. Debian, the high speed train, overtakes Trac, the steam train! an initial list of packages for the first pass of RM could be: $ apt-cache search trac- libnet-trac-perl - Perl client library for Trac libtext-trac-perl - module for formatting text with Trac Wiki Style AFAIK, those two are not Python and can use a remote Trac server, so they can stay. All others need to be removed. if i dont hear anything back withing a week, i'll most likely opening those RM bugs, so that we can work on their transitive dependencies. Just go ahead. I hope, we can reintroduce Trac in one or two years, maybe in time for Debian 12 (bookworm), but probably not for Debian 11 (bullseye).
Help with interpreting piuparts error
Hi, I'm not sure how to interpret this 14799 lines piuparts log: https://piuparts.debian.org/sid/fail/python-aiohttp-session-doc_2.9.0-2.log It says "ERROR: FAIL: Installation and purging test." Any idea what's wrong with the package? TIA! Cheers
Re: Future of Trac in Debian
On 2019-11-29 18:13, Nicholas D Steeves wrote: > IMHO one of the Debian Trac uploaders should post to the #12130 Trac > ticket informing them of our plan. I linked to the email of 2019-10-14: https://trac.edgewall.org/ticket/12130#comment:63
Re: Future of Trac in Debian
On 2019-11-29 16:24, Sandro Tosi wrote: > I know it may sound hard, but is it now time to remove trac from > Debian, and ideally re-introduce it back when it's being ported to > py3k? See also: https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs What would be the alternative? It would be nice to have newer versions (based on Python 2) as backports or sloppy backports for buster, but that will not be possible anymore, as soon as Trac is removed from unstable, right? Btw. Trac development is still active (1.4 released three months ago, but slow, maybe because of lack of developers: "Trac 1.4 is the first major release of Trac in almost 3 years." Trac 1.6 will probably use Python 3. But when? Nobody knows. Cheers
Re: Python 3 transition question
On 9/2/19 1:18 PM, Martin Kelly wrote: On 9/1/19 10:07 PM, Scott Kitterman wrote: On September 2, 2019 4:00:53 AM UTC, Sandro Tosi wrote: I would just stop building these. And if the reverse dependencies have a py2removal bug itself, then comment in these issues that the suggested/recommended package gets removed. If they don't have a py2removal bug, please file the bugs for these packages. i dont believe this is a sensible approach; for example i maintain python-mpmath, that would be rendered uninstallable the moment python-gmp2 is removed. Now, python-mpmath has 3 external reverse-dependencies (just to name a couple, sagemath and simpy) that would be then uninstallable, and so on and so forth for all their rdeps. Martin, i think for now the only option is to keep the py2 packages around until we're ready to drop them (ie they have 0 rdeps). I just checked on packages.d.o and according to it, python-gmp2 is a Suggests. Suggests aren't installed with packages. Unless I'm missing something, python-mpmath wouldn't become uninstallable. IIRC, policy doesn't even require Suggests packages to exist. I agree about keeping packages as long as they have reverse Recommends, but I think Suggests is going too far (although AIUI, missing Recommends don't make the package uninstallable either). Scott K If I'm summarizing correctly, it sounds like there is no policy on exactly what to do here. I think removing the package would be pretty bad, because gmpy is designed to speed up numerical libraries, and the performance hit without it would make many libraries really painful to use. Given this, perhaps the dependencies should be Recommends instead of Suggests. The guidelines I saw in the bugs filed on my packages (e.g. bug #937791) say to "document" the reverse dependency. Where do I document this? (ping). I'd like to resolve the bugs I have on my packages and am not sure yet how best to proceed.
Re: Python 3 transition question
On 9/1/19 10:07 PM, Scott Kitterman wrote: On September 2, 2019 4:00:53 AM UTC, Sandro Tosi wrote: I would just stop building these. And if the reverse dependencies have a py2removal bug itself, then comment in these issues that the suggested/recommended package gets removed. If they don't have a py2removal bug, please file the bugs for these packages. i dont believe this is a sensible approach; for example i maintain python-mpmath, that would be rendered uninstallable the moment python-gmp2 is removed. Now, python-mpmath has 3 external reverse-dependencies (just to name a couple, sagemath and simpy) that would be then uninstallable, and so on and so forth for all their rdeps. Martin, i think for now the only option is to keep the py2 packages around until we're ready to drop them (ie they have 0 rdeps). I just checked on packages.d.o and according to it, python-gmp2 is a Suggests. Suggests aren't installed with packages. Unless I'm missing something, python-mpmath wouldn't become uninstallable. IIRC, policy doesn't even require Suggests packages to exist. I agree about keeping packages as long as they have reverse Recommends, but I think Suggests is going too far (although AIUI, missing Recommends don't make the package uninstallable either). Scott K If I'm summarizing correctly, it sounds like there is no policy on exactly what to do here. I think removing the package would be pretty bad, because gmpy is designed to speed up numerical libraries, and the performance hit without it would make many libraries really painful to use. Given this, perhaps the dependencies should be Recommends instead of Suggests. The guidelines I saw in the bugs filed on my packages (e.g. bug #937791) say to "document" the reverse dependency. Where do I document this?
Python 3 transition question
Hi, I maintain python-gmpy and python-gmpy2, which need to transition to Python 3. However, they have several packages that have Suggests or Recommends (not a hard dependency) pointing to python-gmpy/python-gmpy2. These other packages appear to be Python 2 only. Should I stop building the Python 2 versions of these packages (and invalidate the Suggests/Recommends of these other packages), or should I instead just document this issue? If I document it, where should this documentation go? Thanks, Martin
Re: dropping python2 [was Re: scientific python stack transitions]
On 2019-07-08 10:00, Elena ``of Valhalla'' wrote: > I don't think it would be accepted by backports, since it goes against > the requirement that stuff in backports is in testing (and meant to > remain there when it becomes stable). I'm not sure, but building an additional binary package from the same source package might be OK for bpo. Of course, d/control etc. would differ, but that's common.
Re: Please enable me pushing to python-team/applications
On 2019-03-21 00:47, Thomas Goirand wrote: > Can't you guys just simply give write access to Andreas? What's the > issue? Why is it taking so long? This really give the feeling the "team" > is still very much dysfunctional, Maybe two, three people more can get "owner" permissions?
Remove python-social-auth?
Hi, I like to make python-social-auth a transitional package which installs social-auth-core and social-auth-app-django. Which is practically the new project by upstream. Or just remove it? We don't want python-social-auth in buster, do we? TIA & Cheers
Re: Dropping Python 2 support for web.py before buster
On 2019-02-04 12:14, Raphael Hertzog wrote: > Anyway, the fact that we have one known user should not forbid you > to go forward with all this. I will change the Kali infrastructure > to use something else, most likely buildd and wannabuild. Or maybe port rebuildd to Python 3?
Re: Help with setuptools-related build break
On 1/26/19 4:56 PM, Scott Kitterman wrote: On Saturday, January 26, 2019 04:05:50 PM Martin Kelly wrote: Hi, I'm attempting to release a new version of my package python-gmpy2 [1] and am hitting a bug that I can't figure out how to resolve. Specifically, in the latest version under pbuilder, python-setuptools is missing. When I add python-setuptools and python3-setuptools it to the build dependencies, I get the following error: Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 python-pkg-resources all 39.2.0-1 404 Not Found [IP: 151.101.52.204 80] Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 python-setuptools all 39.2.0-1 404 Not Found [IP: 151.101.52.204 80] Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 python3-setuptools all 39.2.0-1 404 Not Found [IP: 151.101.52.204 80] E: Failed to fetch http://cdn-fastly.deb.debian.org/debian/pool/main/p/python-setuptools/python -pkg-resources_39.2.0-1_all.deb: 404 Not Found [IP: 151.101.52.204 80] E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' to continue with missing packages [snip] E: pbuilder-satisfydepends failed. Indeed, this package version does not exist in the repo, so I'm not sure why apt is attempting to install it. Does anyone have some guidance and/or debugging suggestions? Thanks, Martin [1] https://salsa.debian.org/python-team/modules/python-gmpy2 Those are obsolete versions. You need to run pbuilder update. Scott K Thanks, this is what I thought as well, and so I kept running pbuilder update to no avail. I realized that I was using cowbuilder, so the update was happening on a different chroot. After starting from a clean cowbuilder, the problem is gone.
Help with setuptools-related build break
Hi, I'm attempting to release a new version of my package python-gmpy2 [1] and am hitting a bug that I can't figure out how to resolve. Specifically, in the latest version under pbuilder, python-setuptools is missing. When I add python-setuptools and python3-setuptools it to the build dependencies, I get the following error: Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 python-pkg-resources all 39.2.0-1 404 Not Found [IP: 151.101.52.204 80] Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 python-setuptools all 39.2.0-1 404 Not Found [IP: 151.101.52.204 80] Err http://cdn-fastly.deb.debian.org/debian sid/main amd64 python3-setuptools all 39.2.0-1 404 Not Found [IP: 151.101.52.204 80] E: Failed to fetch http://cdn-fastly.deb.debian.org/debian/pool/main/p/python-setuptools/python-pkg-resources_39.2.0-1_all.deb: 404 Not Found [IP: 151.101.52.204 80] E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' to continue with missing packages [snip] E: pbuilder-satisfydepends failed. Indeed, this package version does not exist in the repo, so I'm not sure why apt is attempting to install it. Does anyone have some guidance and/or debugging suggestions? Thanks, Martin [1] https://salsa.debian.org/python-team/modules/python-gmpy2
Re: Dropping Python 2 support for web.py before buster
On 2019-01-22 15:02, Julien Danjou wrote: > I'm not actively maintaining rebuildd for years now. I'm not even sure > it has still any user. I wouldn't spend time on porting rebuildd nor I > would let it block it updating web.py. > Not sure what's the other solution would be (removal?) but if you have > any idea, go ahead. OK, I'll upload web.py without Python 2 support then. If someone has strong interest in rebuildd, they has to make a Python 3 version anyway. If the package is not in buster, there can still be a backport. Thanks for your input, Julien, Julien, and Mattia!
Re: Dropping Python 2 support for web.py before buster
Quoting Mattia Rizzolo : On Tue, Jan 22, 2019 at 12:18:09PM +0100, W. Martin Borgert wrote: I'm going to package the latest git master of web.py¹, because of Python 3.7 compatibility. It has a new dependency on cheroot², which has only a Python 3 version in Debian. I could ask Julien to provide a Python 2 package of cheroot for buster, but I prefer to drop Python 2 support of web.py instead. Any opinions? I would say "go for the drop!!!" if not for the presence of a reverse dependency of the python2 package (rebuildd). So IMHO the best would be: * port rebuildd to py3 * drop the py2 package Julien & Julien, how realistic is moving rebuildd³ to Python 3 for buster? Or better upload cheroot with Python 2 support for now? The update of web.py is, unfortunately, necessary for Python 3.7. Cheers ¹https://tracker.debian.org/webpy ²https://tracker.debian.org/python-cheroot ³https://tracker.debian.org/rebuildd
Dropping Python 2 support for web.py before buster
Hi, I'm going to package the latest git master of web.py¹, because of Python 3.7 compatibility. It has a new dependency on cheroot², which has only a Python 3 version in Debian. I could ask Julien to provide a Python 2 package of cheroot for buster, but I prefer to drop Python 2 support of web.py instead. Any opinions? Cheers ¹https://tracker.debian.org/webpy ²https://tracker.debian.org/python-cheroot
cssutils salsa PR review or permission update
Hello Pythoneers, The other day I worked a bit on the cssutils package (I'm a co-maintainer). But then I noticed that since the salsa migration I can't commit to the official packaging git any more, so I sent a PR instead: https://salsa.debian.org/python-team/modules/cssutils/merge_requests/1/commits Does the Python modules team receive notifications about these? I don't mind much working through PRs, or perhaps it's possible to add me as a committer for cssutils on the salsa repo? I just wouldn't like to upload a new version and leave the VCS out of date. Thanks for any suggestions, Martin
Re: Matplotlib 3.0 - update ok?
Quoting Steffen Möller : Now, I am tempted to create a package matplotlib3 instead of forcing everyone to update from this long term release (see https://matplotlib.org/). Any opinions from your sides? I wonder, whether it's easier to wait for buster and then create an orange backport? I'm sure, immediately after release, we (= Python teams) will start to drop Python 2 support anyway. In the mean time new versions of matplotlib and friends, as well as orange, might be suitable for experimental, so that your packaging work doesn't need to wait. Orange looks very interesting and is a welcome addition to Debian, btw.!
Re: git-dpm -> gbp conversion (mass-change)
On 2018-08-03 10:08, W. Martin Borgert wrote: > On 2018-08-03 08:04, Simon McVittie wrote: > > There is no upstream/master, upstream/unstable, upstream/stretch or > > similar in DEP-14, because: > > I did not suggest mingling upstream branches with Debian > versions, which seems to be your impression. I just (maybe > wrongly) thought, that upstream/master whatever upstream does in ^ follows > their master/tip/trunk (just as upstream/latest always follows > the latest upstream release). I don't remember, where I got that > idea from. Unreliable sources :~)
Re: git-dpm -> gbp conversion (mass-change)
On 2018-08-03 08:04, Simon McVittie wrote: > There is no upstream/master, upstream/unstable, upstream/stretch or > similar in DEP-14, because: I did not suggest mingling upstream branches with Debian versions, which seems to be your impression. I just (maybe wrongly) thought, that upstream/master whatever upstream does in their master/tip/trunk (just as upstream/latest always follows the latest upstream release). I don't remember, where I got that idea from. Unreliable sources :~)
Re: git-dpm -> gbp conversion (mass-change)
On 2018-08-03 04:33, Scott Kitterman wrote: > On August 3, 2018 3:51:00 AM UTC, "W. Martin Borgert" > wrote: > >How about changing "upstream" to "upstream/latest" (for upstream > >releases, typically for unstable) and "upstream/master" (for > >following upstream master, typically for experimental)? > > I think we should just follow DEP-14 branch naming conventions (which, having > re-read it, I discover I haven't been doing). In fact, I thought that "upstream/master" were DEP-14-ish, but only "upstream/latest" (for the newest release) is.
Re: git-dpm -> gbp conversion (mass-change)
On 2018-08-03 11:06, Ondrej Novy wrote: > 2. change default branch to debian/master How about changing "upstream" to "upstream/latest" (for upstream releases, typically for unstable) and "upstream/master" (for following upstream master, typically for experimental)?
Request to join the Python Modules team
Hi, I would like to join the Salsa Python Modules team in order to continue maintaining my package python-gmpy2. I previously had Alioth access and have finally had time to migrate to Salsa. My Salsa login is aomighty-guest. I have attempted to read and accept the Python Modules policy (https://python-modules.alioth.debian.org/python-modules-policy.html), as stated in https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin, but the link is dead. Thanks, Martin
Name of the upstream branch
Dear team, https://wiki.debian.org/Python/GitPackagingPQ#Git_Branch_Names states: "we are strongly recommending you use DEP-14 style branch names" and below: "upstream - The un-Debianized upstream source." I ask to change the latter branch name to "upstream/latest", first, because that's what DEP-14 says, and second, because "upstream/" is necessary anyway in some cases and is less confusing then. Objections? TIA from the ministry of silly bike shedding.
Re: Backport of Python 3.6 for Debian Stretch?
Quoting Nguyễn Hồng Quân : Python 3.6 has much better performance than Python 3.5, especially on embedded computer (I tried and compared). This is interesting! Did you also compare Python 2.7 with 3.5/3.6? I'm looking for more reasons to finally port my embedded software :~)
Re: Backport of Python 3.6 for Debian Stretch?
Quoting Nguyễn Hồng Quân : We write an application which needs Python 3.6. Could you elaborate, why you need Python 3.6 instead of 3.5? Maybe there is a way to make your application work with 3.5? E.g. by backporting specific modules?
Re: Where to put docs of a -doc package for python 2 + 3 modules?
Quoting Thomas Goirand : Which is why I think we should have standardize on python-foo for the source package (which is what I do). Same here, even if foo is not yet taken. Save the environment, do not pollute the global packages namespace! :~)
Re: Where to put docs of a -doc package for python 2 + 3 modules?
On 2018-03-12 23:15, Thomas Goirand wrote: > But what now that python-foo is gone? Should I rename the doc package? No, but that's just my gut feeling.
Re: Where to put docs of a -doc package for python 2 + 3 modules?
Quoting Simon McVittie : In python-mpd-doc and python-dbus-doc, I installed the real documentation files in /u/s/d/python-*-doc, but placed symlinks to them in both /u/s/d/python-* and /u/s/d/python3-*. Perhaps that's a reasonable way to achieve the spirit of the Policy §12.3 recommendation while not privileging one of Python 2, Python 3, PyPy, etc. over the others? Nice idea, I'll do the same. Thanks!
Where to put docs of a -doc package for python 2 + 3 modules?
Hi, policy (12.3) says, that putting the contents of package-doc into /usr/share/doc/package/ (main package) is preferred over /usr/share/doc/package-doc/. debhelper detects the Python 2 package as main package. One can override this to the path for the Python 3 package, but both feels wrong to me. Even if we drop Python 2 at some point, maybe then there is Python 4 or PyPy. I tend to stay with the traditional path, and ignore the preference of our beloved policy. Not without first consulting this very mailing list, of course. Opinions? TIA & Cheers
Re: PAPT migrated to Git on Salsa
On 2018-02-24 23:49, Stefano Rivera wrote: > 'trac-batchmodify', > 'trac-git', The functionality of those two is now part of trac itself. We might want to keep them for LTS purposes until they are not part of any LTS release anymore. But I don't care much...
Re: Help proposed for migration of PAPT repos to Salsa
Quoting Stefano Rivera : I didn't get much review last time, but there did seem to be a general +1 From me not only "+1", but also "thank you"!
PAPT repo at salsa.d.o open for new packages now?
Hi, if I have a Python program, that currently is not yet maintained by PAPT, but want to move it to the team: May I use salsa.d.o/python-team/applications/ now? Any objections? TIA & Cheers
Re: Move to salsa? Team structure preview ready
Quoting Ondrej Novy : 2018-02-08 10:14 GMT+01:00 Ondrej Novy : I created team "python-team" in salsa with 3 subgroups: interpreter modules applications OK. I can do DPMT GIT migration, but I need agreement on new structure. OK! :~) We can merge two subgroups later. No need to merge the subgroups ever. With this structure, it is one team already. If there nobody objects, we have to: - migrate the git archives (you volunteered, thanks!) - ask for membership in the team (everybody) - change Python team documentation (who?) - make an MR for https://salsa.debian.org/salsa/AliothRewriter (who?) - ?
Re: Merge modules and apps team?
On 2018-02-07 09:58, Matthias Klose wrote: > I don't think that is a good idea. Both teams are not very active when it > comes > to address RC issues and updating to new upstream versions. From my point of > view the apps team is worse than the modules team in this regard. In fact, this is one of the reasons I like to merge them. I hope, that the slightly better situation of the modules will rub off on the apps. My illusions might be in vain, but at least I do not see any disadvantage in the merge.
Move to salsa? Merge modules and apps team?
Hi, how about moving the Python team(s) to salsa? And how about merging the modules and apps teams into one? Moving git packages (modules team) is very easy using import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git Moving svn packages (apps team) is probably more work. Any opinions? Any doubts? TIA & Cheers
Re: Update wokkel?
On 2017-10-27 17:26, Angel Abad wrote: > Because there is no official release with these changes, I will > write upstream developer and I will tell you. Was there any outcome? TIA!
Help the orphans! (here: Python modules)
Hi, unfortunately, I had to orphan some packages: python-activipy -- implementation of ActivityStreams 2.0 (#882871) python-mpld3 -- D3 viewer for matplotlib (#882858) python-mplexporter -- general matplotlib exporter (#882857) python-odoorpc -- pilot Odoo servers through RPC (#882870) python-oerplib -- Python client library to Odoo server (#882868) Maybe somebody likes to take over one or the other? TIA & Cheers
Re: Update wokkel?
On 2017-10-27 17:26, Angel Abad wrote: > Because there is no official release with these changes, I will > write upstream developer and I will tell you. Very good, thanks! You can reach him via xmpp:ral...@ik.nu > I you want to co-maintain wokkel package we could talk about it. Well, it is not that I really want to, but a software I like to use, sat_pubsub, depends on wokkel. sat_pubsub is currently Python 2, and the developer, goffi, will port it to Python 3 sooner or later. Therefore I have some interest in a working wokkel and would co-maintain it gladly, if this were of any help! signature.asc Description: PGP signature
Update wokkel?
Hi Angel and team, would you mind, if I update wokkel and close #735304 (teams git repo) and #879712 (Python 3 support)? I would add myself to uploaders, too. TIA & Cheers signature.asc Description: PGP signature
Re: pycharm package in debian
On 2017-10-02 10:37, Thomas Goirand wrote: > On 10/01/2017 11:50 PM, Matthias Klose wrote: > > Do you want point users to the five year lagging behind eclipse package in > > Debian? > > Why 5 years? We do release stable approx every 2.5 years... 5 years minus 12 days: Eclipse 3.8.1 has been uploaded to Debian on 2012-10-14. Cheers
Re: pycharm package in debian
On 2017-10-01 23:16, Andrey Rahmatullin wrote: > On Sun, Oct 01, 2017 at 04:52:55PM +0200, W. Martin Borgert wrote: > > I usually start to use software, when it arrives in Debian. > > Or I package it. If there is some snap or other third party > > package, I'm unsure how to work with it: > > > > How to install? > I expand the tarball to ~ ... This is my point: I'm too lazy and too old to find out for every random application how to install, uninstall, upgrade it, find out which version, if any, is installed on my system, whether the software complies with the DFSG, etc. > Surely you don't expect the Debian maintainers to fix bugs you could > encounter in PyCharm? I expect Debian maintainers to forward bugs to upstream, if they assume, that the bug is not introduced by them. (For some highly complex software, like Gnome or KDE, this is not practical, but for many packages this should work.) Cheers
Re: pycharm package in debian
On 2017-10-01 17:16, Ghislain Vaillant wrote: > Most likely a lot. We are talking about a large application with probably > quite a few dependencies in Java / Kotlin. > > Why not? Because failure to commit to regular updates would feed the > current narrative that Debian ships old and loosely maintained software. > Especially when there are other means of installing the software which are > officially documented upstream. > > I have been there with packages I personally maintain (spyder for > instance), and I am raising these concerns out of my own experience and > feedback from existing users. Feel free to disregard. Those are absolutely valid concers. I'm aware of many outdated packages, including some maintained by me. I leave the challenge to those, who like to package it. Still, if PyCharm were in Debian, I would at least try it out some day. Cheers PS: Is there maybe something broken with the quoting function of your MUA? I cannot differentiate between text written by you and quoted text. There is no '> ' or whatever...
Re: pycharm package in debian
On 2017-10-01 08:26, Ghislain Vaillant wrote: > May I ask what would be the benefit for pycharm to be in Debian, when we > already have the official Jetbrains Toolbox App or the snap package as means > to install and update the application? I usually start to use software, when it arrives in Debian. Or I package it. If there is some snap or other third party package, I'm unsure how to work with it: How to install? How to uninstall? How to report bugs and to whom? How to download the source code and rebuild it? Is it DFSG-free anyway? (Does it already build reproducible?) There is nothing wrong with having snap or other packages available, but I'm not their target audience. But I'm an Emacs - and vi! - user anyway :~) Another question is, how much work it will be and whether it is worth the effort, esp. permanent maintenance. But if somebody wants to do it, why not? Cheers
Re: Docs only packages?
On 2017-09-24 10:35, Diane Trout wrote: > What do people think about having documentation only packages? Good thing. Like manpages etc. signature.asc Description: PGP signature
Re: Question about binary sphinx inventory files
On 2017-08-26 11:42, Dmitry Shachnev wrote: > https://codesearch.debian.net/search?q=html%2Fobjects%5C.inv+path%3Adebian%2Fpatches%2F.* I should use codesearch more often :~) And "searx" should have a backend for it!
Re: Question about binary sphinx inventory files
On 2017-08-25 22:36, Tristan Seligmann wrote: > In the case of Python's documentation inventory specifically, this is built > and distributed in the python*-doc packages, and there should be no need to > download it from python.org. Thanks! I use the packaged file now in python-simpy3. AFAIK, only python-numpy still uses a downloaded .inv.
Question about binary sphinx inventory files
Hi, I believe that a small number of Python module doc packages use binary Sphinx inventory (.inv) files during build, that are just downloaded from python.org by the package maintainer. I don't know anything about Sphinx nor how to encode/decode .inv files. https://pypi.python.org/pypi/sphobjinv is not in Debian, is it? How would I create e.g. https://docs.python.org/objects.inv from which sources? TIA & Cheers
Uploading Python modules which drop support for Python 2?
Hi team, pysolar upstream version 0.7 dropped support for Python 2, so I did not upload it for stretch. I'm considering upload for buster now. What do you think? Cheers signature.asc Description: PGP signature
Re: django-cms in Debian?
Quoting Dominik George : at Teckids, we are about to start using Django CMS for our website. We have a policy to only use Debian stable/main if at all possible. This is a very useful policy! So I wonder whether there is a reason django-cms is not in Debian? (Apart from "noone started maintaining it" ;) No, it's just "work", as far as I know. In other words, before I start packaging django-cms and its missing dependencies, is there anything I should know? Just read https://bugs.debian.org/516183, I'm sure I'm not the only one who very much appreciates having Django CMS in Debian! Cheers
Re: PAPT git migration
Many thanks, Stefano, for your work on this! On 2017-05-31 20:58, Stefano Rivera wrote: > * trac-batchmodify: OK > * trac-git: missing a tag [DONE] Those two are only in oldstable. Not sure whether it is worth to migrate them at all. > * trac-privateticketsplugin: missing some tags [DONE] This git repository should probably renamed to trac-privatetickets. Cheers
Re: alioth python-apps access for moschlar-guest
Typo: it should read moschlar-guest Am 27.12.2016 um 11:50 schrieb Christoph Martin: > Der Python-Apps Alioth project maintainers, > > please give moschlarb-guest access rights to the repositories in > python-apps. He wants to help maintain together with me nagstamon. > > Regars > Christoph > -- ======== Christoph Martin, Leiter Unix-Systeme Zentrum für Datenverarbeitung, Uni-Mainz, Germany Anselm Franz von Bentzel-Weg 12, 55128 Mainz Telefon: +49(6131)3926337 Instant-Messaging: Jabber: mar...@uni-mainz.de (Siehe http://www.zdv.uni-mainz.de/4010.php) <> signature.asc Description: OpenPGP digital signature
alioth python-apps access for moschlarb-guest
Der Python-Apps Alioth project maintainers, please give moschlarb-guest access rights to the repositories in python-apps. He wants to help maintain together with me nagstamon. Regars Christoph -- Christoph Martin, Leiter Unix-Systeme Zentrum für Datenverarbeitung, Uni-Mainz, Germany Anselm Franz von Bentzel-Weg 12, 55128 Mainz Telefon: +49(6131)3926337 Instant-Messaging: Jabber: mar...@uni-mainz.de (Siehe http://www.zdv.uni-mainz.de/4010.php) <> signature.asc Description: OpenPGP digital signature
Re: [Python-modules-commits] [python-social-auth] 55/89: Merge pull request #821 from open-craft/saml-no-idp
On 2016-12-24 10:48, Sandro Tosi wrote: > what's all this? 89 commits? are you pulling commits from upstream > git? this looks just spam to the mailing list Sorry, this was not intended. I pulled upstream in fact, but I was not aware that I was pushing it to our git, too. :~(
Re: DEP 8: Gathering Django usage analytics
Quoting Barry Warsaw : I'd love to know if there's a Debian-wide policy on such things. E.g. if "opt-out with informed user consent" was an official policy that we could clearly point to and reference, it would greatly help provide guidance to both Debian maintainers and upstreams. In the issue at github someone already points out that popcon is "opt-in" and I'm sure, that the overwhelming majority in Debian is in favour of it in contrast to "opt-out". I can understand, that upstream would prefer the latter, but Debian has a reputation for taking privacy issues very serious and likes to keep it. Not sure about any policy on this, though. If Django implements usage analytics, I would strongly suggest to make it "opt-in" in Debian, just as popcon, not "opt-out". Cheers
Joining the team
Hi, > Why you want to join the team: e.g. maintain your current packages within the team, help maintain some specific packages, etc. I want to maintain new package python3-geoip2 (and others). And I want to help with other packages too. > Your Alioth login. krata-guest > A statement that you have read https://python-modules.alioth.debian.org/policy.html and that you accept it. I read the policy and I'm accepting it. Thanks -- Ing. Martin Kratochvíl
Re: can we disable the bounce kicker? Re: confirm
On 2016-09-10 17:29, Sandro Tosi wrote: > in some countries (italy to name one) you would be > breaking the law accepting emails and not delivering them to the > recipient. Same in Germany, AFAIK.
Re: on keep providing python 2 packages
On 2016-08-19 08:19, Sandro Tosi wrote: > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? Yes.
Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)
On 2016-08-10 10:18, Thomas Goirand wrote: > Instead of > accepting the merge, and resolving conflicts later on, git-dpm goes into > the rebase conflict mode of Git, and it's often not obvious what to do > there. Messing-up everything, and restart from scratch (and then iterate > until done properly) isn't uncommon. Been there, lost hours :~( > As I only heard complains about git-dpm, maybe someone would like to > express his joy using it, and explain why they think it's a nice tool. > But is there such person? It seems git-dpm only brings frustration. Well, in most cases I did not have any problems with it. Points I like and would prefer not to change: - no need to use quilt - no special build command, just plain dpkg-bp or whatever The idea to try something else in PAPT is very welcome from my side, no matter what tool.
PAPT Git (was: pypi2deb 1.20160809 and --profile dpmt)
On 2016-08-09 23:28, Daniel Stender wrote: > On this occasion ... let it be me to start the discussion: let's get into Git > also for Python Apps soon. A common VCS for both DPMT and PAPT would be nice, indeed. (I have been reminded rightfully by both Piotr and Sandro, that PAPT still uses SVN. Changing that would increase my fun level!)
Re: removing $(PYBUILD_NAME).egg-info with clean target in debian/rules?
Greetings Piotr and Ondrej, >> Problem description: when I run 'debclean' or 'debian/rules clean', >> I still have a directory called 'tldp.egg-info'. I don't want it to >> remain after 'clean'. > >pybuild removed that in the past, but some tools complained so I >disabled this feature. You can get it back by adding >"foo.egg-info/*" to debian/clean file. It's OK to remove it in >clean target - these files will be regenerated. Excellent! >I'm using this: > ># cat debian/source/options >extend-diff-ignore = "^[^/]*[.]egg-info/" > >and keeping .egg-info here. > >But if you don't want it here, use dh_clean OR create file debian/clean >(man dh_clean for complete doc). I will do that. Thank you both for your quick replies. Best, -Martin -- Martin A. Brown http://linux-ip.net/
removing $(PYBUILD_NAME).egg-info with clean target in debian/rules?
Hello all, I'm trying to prepare a package (tldp, python3-tldp) for acceptance. I have mentor support from sponsor Gianfranco Costamanga (under bug #822722). My build works. It was really easy using the pybuild system. Thank you to whomever wrote that. Problem description: when I run 'debclean' or 'debian/rules clean', I still have a directory called 'tldp.egg-info'. I don't want it to remain after 'clean'. Therefore, I added the following fragment to my rules (please ignore the removal of the Sphinx _build dir): override_dh_clean: (cd docs && \ rm -rf -- ./_build) rm -rf -- ./$(PYBUILD_NAME).egg-info dh_clean Gianfranco's comment is that I should not need to remove this .egg-info thing myself. Is there a better way to remove $(PYBUILD_NAME).egg-info? Is the 'clean' target not the right one? Is there a 'distclean' or something else I should be using? Thank you in advance, -Martin [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822722 -- Martin A. Brown http://linux-ip.net/
Re: Autopkgtest smoke test for Python libraries
Hey Barry, Barry Warsaw [2016-03-01 10:48 -0500]: > I gather that it's supposed to be used by the maintainer in a source package > ($vcs repo) to jumpstart a debian/tests directory? You could use it for that purpose indeed, but that's not really what it is intended for. The idea is that the generic tests apply to all packages of a particular type, so you can change them centrally instead of having to modify and upload hundreds of packages. There is one more thing, though: The test machinery needs to be able to discover that a package has an autodep8 test (without having the source package already available, as getting and checking that is very expensive). So ideally all source packages which want to use that will get a "Testsuite: autopkgtest-pkg-python" header in debian/control, like for example libnet-oauth-perl. However, until these get uploaded we can add some custom code to debci to recognize those packages based on the name and dependencies (that's what we did for bootstrapping the perl and ruby autodep8 tests). > I'm not sure how useful things like "setup.py test" are for DEP-8. In general > I think a package's test suite are best exercised during package build[*]. During package build is of course good, but one of the points of autopkgtest is to run the tests when one of your dependencies change (and thus potentially break you). > For the majority of Python packages, I view DEP-8 as ensuring that the user > experience is what they expect, and that means at a minimum that the packages > import and Do Something Simple. A generic proof of non-broken import can mean > printing the package's version or the module path, and that's something that > autopkg8 could templatize. Anything more than that requires some more > detailed knowledge about what the package does. As I said, running upstream tests works surprisingly well for Perl/Ruby, we had about 80% success rate. But they are a bit more rigid in structure apparently. But indeed, ensuring that your module still imports already says a lot. New dependencies can still break your module in subtle ways, but at least things like new/removed Python versions, linker errors, wrong paths etc. are spotted. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature