Re: PEP-517/PEP-518 Support In Debian: current state
* Louis-Philippe Véronneau: " Re: PEP-517/PEP-518 Support In Debian: current state" (Mon, 25 Oct 2021 15:28:17 -0400): > On 2021-10-25 14 h 04, Mathias Behrle wrote: > > * Mathias Behrle: " PEP-517/PEP-518 Support In Debian: current state" (Mon, > > 25 Oct 2021 19:45:39 +0200): > > > >> Hi all, > >> > >> before doing something nasty I would like to hear if > >> https://lists.debian.org/debian-python/2020/06/msg2.html > >> is still valid? > > > > JFTR I forgot to mention the background of my question: > > > > Package simpleeval has moved to a setup.py-less build using pypa/build. > > > > Stuart Prescott has done some work to get this in dh-python: > > * https://salsa.debian.org/python-team/packages/python-installer > > * https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/20 Thanks for the heads-up, pollo! -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpKeVwdw1R6f.pgp Description: Digitale Signatur von OpenPGP
Re: PEP-517/PEP-518 Support In Debian: current state
* Mathias Behrle: " PEP-517/PEP-518 Support In Debian: current state" (Mon, 25 Oct 2021 19:45:39 +0200): > Hi all, > > before doing something nasty I would like to hear if > https://lists.debian.org/debian-python/2020/06/msg2.html > is still valid? JFTR I forgot to mention the background of my question: Package simpleeval has moved to a setup.py-less build using pypa/build. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpQTixA4P11D.pgp Description: Digitale Signatur von OpenPGP
PEP-517/PEP-518 Support In Debian: current state
Hi all, before doing something nasty I would like to hear if https://lists.debian.org/debian-python/2020/06/msg2.html is still valid? Thanks for your feedback, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpHy539zkl8E.pgp Description: Digitale Signatur von OpenPGP
Re: Autoremoval mails for python-passlib
* Sebastian Ramacher: " Re: Autoremoval mails for python-passlib" (Sat, 28 Mar 2020 10:25:47 +0100): > On 2020-03-28 10:01:29, Mathias Behrle wrote: > > Hi all, > > > > I got this morning a whole bunch of autoremoval mails for the Tryton suite > > for dependency python-passlib, see below. > > > > That could be correct if the server (the only package using passlib) would > > use that package. But the server package was converted to Python3 more than > > two years ago: > > > > https://salsa.debian.org/tryton-team/tryton-server/-/commit/c22d768dbe55a3293d7d9dba6116972c5218aa9d > > > > and *never ever* used python-passlib, but directly python3-passlib > > introduced in > > > > https://salsa.debian.org/tryton-team/tryton-server/-/commit/800d66af286fae3c920aa8a264c6f2a1146f614a > > > > Can someone tell me what is going on here? > > python-passlib and python3-passlib are built from the same source > package src:python-passlib. If the package is flaged for autoremoval, > this affects reverse dependencies of both packages, so also the reverse > dependencies of python3-passlib. Thanks for the explanation. While the message buggy deps python-passlib is quite misleading I see the package was just fixed. Cheers -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Autoremoval mails for python-passlib
-modules-stock-package: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-product-location: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-shipment-measurements: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-split: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-supply-day: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-supply-forecast: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-supply-production: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock-supply: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-stock: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-timesheet-cost: buggy deps python-passlib, flagged for removal in 29.2 days tryton-modules-timesheet: buggy deps python-passlib, flagged for removal in 29.2 days tryton-server: buggy deps python-passlib, flagged for removal in 29.2 days -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: [tryton-debian] Bug#877849: Namespace conflict for python-magic
* Christoph Biedl: " Re: [tryton-debian] Bug#877849: Namespace conflict for python-magic" (Mon, 15 Jan 2018 09:37:51 +0100): Hi Christoph, > Mathias Behrle wrote... > > > I found > > > > $ apt-cache rdepends python-magic > (...) > > Yeah, I already had checked a few of them where possible with little > efforts. These were the test I had been talking of (actually, including > python3-magic rdeps as well). > > > May be we should signal them explicitely to test the new package in > > experimental? What do you think? > > My plan is to send a call for testing to debian-devel once python-magic > has been accepted. It shouldn't hurt to add the dd-list output for these > packages. That would be 27 addresses. I might be convinced to send out > individual notices - but I think that's exaggerting. Odds for bugs are > fairly low, and there's still a lot of time until the buster freeze to > detect and fix them. > > Christoph, it's called "unstable" for a reason JFTR: relatorio_0.8.0-1~exp1 was just built and uploaded. It builds against python-magic (>=2:0.4.15-1~exp1) and all tests are passing succesfully. Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpxeGjmgUq8Y.pgp Description: Digitale Signatur von OpenPGP
Re: Bug#877849: [tryton-debian] Namespace conflict for python-magic
* Christoph Biedl: " Re: Bug#877849: [tryton-debian] Namespace conflict for python-magic" (Sun, 14 Jan 2018 21:30:22 +0100): > Christoph Biedl wrote... > > > Hence, here is a preliminary packaging of python-magic for Debian: > > > > > > https://www.in-ulm.de/~cbiedl/debian/python-magic/python-magic_0.4.15-1~exp1.dsc > > > > Debianites, please give it a try. > > No reaction of any kind, so just uploaded to experimental. Let the games > begin. > > Christoph Thanks, Christoph. I found $ apt-cache rdepends python-magic python-magic Reverse Depends: alot dff syslog-summary s3cmd rpmlint fdroidserver autoradio apt-offline alot lava-dispatcher check-all-the-things syslog-summary python-swiftsc rpmlint rows lava-dispatcher python-ginga python-eyed3 autoradio May be we should signal them explicitely to test the new package in experimental? What do you think? Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: [tryton-debian] Namespace conflict for python-magic
* Adam Hupp: " Re: [tryton-debian] Namespace conflict for python-magic" (Mon, 4 Dec 2017 11:58:22 -0800): Hi Christoph, while approaching the test for relatorio I got aware, that the result won't be very significant, because relatorio depends anyway on python-magic[pypi]. To get meaningful results it would be much better to get the compatibility layer tested with packages depending on python-magic[file-magic]. What do you think will be the best way? I think best could be to get a prepared package with the compatibility layer on experimental and to request the dependencies to give it a try. Best wishes for hte New Year! Mathias > I've pushed an update here: > > https://github.com/ahupp/python-magic/tree/libmagic-compat > > It includes a copy of libmagic's bindings, wrapped in deprecation > warnings. So apps should work regardless of which they depend on. > Could you take a look and see if this works for your case? > > On Fri, Oct 27, 2017 at 5:44 AM, Mathias Behrle <mathi...@m9s.biz> wrote: > > * Mathias Behrle: " Re: [tryton-debian] Namespace conflict for > > python-magic" (Thu, 5 Oct 2017 12:01:16 +0200): > > > > Hi Adam, > > > > are there any news on the subject? > > > > The release of Tryton, that will require python-magic is scheduled for next > > week. It would be a great service to our users and simplify things a lot, > > if we had a common python-magic in place. Please let us know, if we can > > help with the planned merge. > > > > Thanks, > > Mathias > > > > > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > > > > > > > -- > > > > Mathias Behrle > > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 > > AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 > > > -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: [tryton-debian] Namespace conflict for python-magic
* Adam Hupp: " Re: [tryton-debian] Namespace conflict for python-magic" (Mon, 4 Dec 2017 11:58:22 -0800): Thanks a lot, Adam, I will take a look ASAP. > I've pushed an update here: > > https://github.com/ahupp/python-magic/tree/libmagic-compat > > It includes a copy of libmagic's bindings, wrapped in deprecation > warnings. So apps should work regardless of which they depend on. > Could you take a look and see if this works for your case? > > On Fri, Oct 27, 2017 at 5:44 AM, Mathias Behrle <mathi...@m9s.biz> wrote: > > * Mathias Behrle: " Re: [tryton-debian] Namespace conflict for > > python-magic" (Thu, 5 Oct 2017 12:01:16 +0200): > > > > Hi Adam, > > > > are there any news on the subject? > > > > The release of Tryton, that will require python-magic is scheduled for next > > week. It would be a great service to our users and simplify things a lot, > > if we had a common python-magic in place. Please let us know, if we can > > help with the planned merge. > > > > Thanks, > > Mathias > > > > > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > > > > > > > -- > > > > Mathias Behrle > > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 > > AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 > > > -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: [tryton-debian] Namespace conflict for python-magic
* Mathias Behrle: " Re: [tryton-debian] Namespace conflict for python-magic" (Thu, 5 Oct 2017 12:01:16 +0200): Hi Adam, are there any news on the subject? The release of Tryton, that will require python-magic is scheduled for next week. It would be a great service to our users and simplify things a lot, if we had a common python-magic in place. Please let us know, if we can help with the planned merge. Thanks, Mathias > * Adam Hupp: " Re: Namespace conflict for python-magic" (Tue, 3 Oct 2017 > 11:06:38 -0700): > > That's good news, Adam, thanks for it! Looking forward to get your diff. > > Best regards, > Mathias > > > > Sorry about the slow response. This has been a pain for a while. I > > have a provisional diff to merge the two packages. Will give it some > > testing and pass a branch to you folks to take a look. Ideally the > > upstream file package would take it over. > > > > On Wed, Sep 6, 2017 at 1:23 AM, Mathias Behrle <mbeh...@debian.org> wrote: > > > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep > > > 2017 18:24:25 +0200): > > > > > >> Mathias Behrle wrote... > > >> > > >> > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 > > >> > Sep 2017 19:38:56 +0200): > > >> > > >> > > The cleanest solution indeed was to bring both upstreams together and > > >> > > ask them to reconcile the APIs and eventually make one of the both > > >> > > implementations obsolete. As things happen such an attempt was > > >> > > started two years ago but appearently never came to a result.[1] > > >> > > > >> > Agreed, that this would be the cleanest solution, but as you say there > > >> > is little probability, that the two upstreams will work together to > > >> > merge their implementations. > > >> > > >> Still this should be tried first. Also, I'm not that pessimistic, see > > >> below. So let's bring the parties involved into the loop: > > > > > > [...] > > > > > > Thanks for your additional information and initiative to re-launch the > > > merge of the two packages. This reads much better and more optimistic than > > > what I could find until now! Crossing fingers now in the hope for the best > > > outcome for everybody. > > > > > > Cheers, > > > Mathias > > > > > > -- > > > > > > Mathias Behrle > > > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 > > > AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 > > > > > > > > > -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgps5X1urLPmQ.pgp Description: Digitale Signatur von OpenPGP
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Fri, 6 Oct 2017 08:34:04 +0200): > Mathias Behrle wrote... > > > That's good news, Adam, thanks for it! Looking forward to get your diff. > > +1 > > In order to control the transition, I've filed in ITP (intent to > package) for Adam's python-magic as https://bugs.debian.org/877849 Did I misunderstand | Ideally the upstream file package would take it over. ? Perhaps a little bit early, because we didn't see Adams solution, but I would like to understand the goals. Am I right that the intentions are - Add a compatibility layer to python-magic[file] to support the feature set of python-magic[pypi] - Provide in some way on Pypi the same featureset for file-magic and python-magic ? If this would be the case, in my understanding there wouldn't be any need for an ITP or transition, but just the possibility for (Debian) packages needing python-magic[pypi) to use the then compatible python-magic[file]. Best regards, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpzPw_4kLPRE.pgp Description: Digitale Signatur von OpenPGP
Re: Namespace conflict for python-magic
* Adam Hupp: " Re: Namespace conflict for python-magic" (Tue, 3 Oct 2017 11:06:38 -0700): That's good news, Adam, thanks for it! Looking forward to get your diff. Best regards, Mathias > Sorry about the slow response. This has been a pain for a while. I > have a provisional diff to merge the two packages. Will give it some > testing and pass a branch to you folks to take a look. Ideally the > upstream file package would take it over. > > On Wed, Sep 6, 2017 at 1:23 AM, Mathias Behrle <mbeh...@debian.org> wrote: > > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep > > 2017 18:24:25 +0200): > > > >> Mathias Behrle wrote... > >> > >> > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep > >> > 2017 19:38:56 +0200): > >> > >> > > The cleanest solution indeed was to bring both upstreams together and > >> > > ask them to reconcile the APIs and eventually make one of the both > >> > > implementations obsolete. As things happen such an attempt was started > >> > > two years ago but appearently never came to a result.[1] > >> > > >> > Agreed, that this would be the cleanest solution, but as you say there is > >> > little probability, that the two upstreams will work together to merge > >> > their implementations. > >> > >> Still this should be tried first. Also, I'm not that pessimistic, see > >> below. So let's bring the parties involved into the loop: > > > > [...] > > > > Thanks for your additional information and initiative to re-launch the > > merge of the two packages. This reads much better and more optimistic than > > what I could find until now! Crossing fingers now in the hope for the best > > outcome for everybody. > > > > Cheers, > > Mathias > > > > -- > > > > Mathias Behrle > > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 > > AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 > > > -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep 2017 18:45:31 +0200): > Mathias Behrle wrote... > > > So finally I am still quite undetermined what to do to get the actual > > release of relatorio packaged[5] (it will be needed for the next release of > > Tryton). For now there is only one usage of python-magic[6], so probably > > best to patch relatorio for now to use file-magic... > > Since I doubt it's super-urgent, just wait a few weeks to see what's > going to happen. You are right. I tend to work as proactively as possible towards new Tryton releases, the next one being scheduled for 2017-10-30. So there is some time left. > In the best outcome, this issue will resolve itself within the next > weeks. Another idea was to add a compability layer in Debian, probably > by switching to PyPi and providing glue code for the users of the > file(1) version. Since to me it seems PyPi is the saner implementation, > CMIIW. Sounds interesting just in case the above proposed solution will not work. I agree that the PyPi impementation seems to be more complete. > Worst approach: Ship a code copy. Appearently kopanocore, peframe and > sqlmap already do that. You'll have to clean up afterwards, though. We will see. Thanks for your input! > Chri- "The delivery of good medica^W packaging is to do as much nothing > as possible" stoph :) Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpb1hWVXCmkW.pgp Description: Digitale Signatur von OpenPGP
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep 2017 18:24:25 +0200): > Mathias Behrle wrote... > > > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep > > 2017 19:38:56 +0200): > > > > The cleanest solution indeed was to bring both upstreams together and > > > ask them to reconcile the APIs and eventually make one of the both > > > implementations obsolete. As things happen such an attempt was started > > > two years ago but appearently never came to a result.[1] > > > > Agreed, that this would be the cleanest solution, but as you say there is > > little probability, that the two upstreams will work together to merge their > > implementations. > > Still this should be tried first. Also, I'm not that pessimistic, see > below. So let's bring the parties involved into the loop: [...] Thanks for your additional information and initiative to re-launch the merge of the two packages. This reads much better and more optimistic than what I could find until now! Crossing fingers now in the hope for the best outcome for everybody. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpKUPcfZz_lw.pgp Description: Digitale Signatur von OpenPGP
Re: Namespace conflict for python-magic
* Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4 Sep 2017 19:38:56 +0200): > Mathias Behrle wrote... > > > Current python(3)-magic in Debian is built from source package 'file'[0]. > (...) > > OTOH the package providing python-magic on PyPi[3] is provided by another > > Upstream[4]. > > ... and I assume the APIs are not identical? Indeed. > > The cleanest solution for me would look like > > - package file in Debian should provide python(3)-file-magic > > - python-magic should be the package name corresponding to the PyPi package > > python-magic[4] > > This would result in users of the current python-magic (from file) would > be forced into the other one. Unless we (as in Debian) can guarantee > this will work in each and every use case, I fail to see why this should > be considered a clean solution. When saying clean solution I talked about the solution inside Debian. I think it could be made to work, but the result doesn't justify the effort and still wouldn't solve the conflicting namespace. > The cleanest solution indeed was to bring both upstreams together and > ask them to reconcile the APIs and eventually make one of the both > implementations obsolete. As things happen such an attempt was started > two years ago but appearently never came to a result.[1] Agreed, that this would be the cleanest solution, but as you say there is little probability, that the two upstreams will work together to merge their implementations. > Trying to address this conflict in Debian is always only second best. If > this is the only feasible way, it still should leave a choice to users > so they can install the implementation of their own preference. Co- > installability of both package was certainly nice-to-have but will > probably impossible for technical reasons. It is indeed an ugly mess. For me both packages must be co-installable, because the relative rdepends must be usable at the same time. Reading through the issues of python-magic (as on PyPi) the problem of course dates from the very beginning[2], spans multiple issues[3] with currently still open this one[4]. So finally I am still quite undetermined what to do to get the actual release of relatorio packaged[5] (it will be needed for the next release of Tryton). For now there is only one usage of python-magic[6], so probably best to patch relatorio for now to use file-magic... > [1] The file mailing list server is currently down, so I cannot provide > URLs. The Message-IDs are > <CAJTao09xATQYZ3qR-4CR+oOrrqB_W=kyujv8esoe4b3bda5...@mail.gmail.com> > <20151020133008.9b79517f...@rebar.astron.com> Still down:(, If you could provide some content for me that would be nice. Cheers, Mathias [2] https://github.com/ahupp/python-magic/issues/21 [3] https://github.com/ahupp/python-magic/issues/57 https://github.com/LibreTime/libretime/issues/166 ... [4] https://github.com/ahupp/python-magic/issues/33 [5] http://hg.tryton.org/relatorio/file/tip/setup.py -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpzVN9Y5Z4tC.pgp Description: Digitale Signatur von OpenPGP
Namespace conflict for python-magic
Hi Christoph, hi folks, there exists an odd namespace conflict for python-magic. Current python(3)-magic in Debian is built from source package 'file'[0]. According to the included setup.py the package for the python bindings are published as 'file-magic'[1] and are available on PyPi under this name[2]. OTOH the package providing python-magic on PyPi[3] is provided by another Upstream[4]. The cleanest solution for me would look like - package file in Debian should provide python(3)-file-magic - python-magic should be the package name corresponding to the PyPi package python-magic[4] The realization of this solution would create some substantial overhead. Therefore it will be more adequate to find a different, but nevertheless meaningful package name for python-magic from [4]. The ugly, but best name currently on my mind would be python-python-magic. Any thoughts? Cheers, Mathias [0] https://sources.debian.net/src/file/ [1] https://sources.debian.net/src/file/1:5.31-1/python/setup.py/ [2] https://pypi.python.org/pypi/file-magic/0.3.0 [3] https://pypi.python.org/pypi/python-magic/ [4] http://github.com/ahupp/python-magic -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
python-relatorio: where to put the test suite?
Hi all, relatorio has a test suite containing some images, documents and templates, which according to FHS should belong under /usr/share. Short question: - does this justify a common package, from which linking to the python2 and python3 package - or is it just preferable to move the tests to docs (on dh_install) - or is there a better solution, which I am currently not aware of? Thanks, Mathias [1] https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=tryton/relatorio.git;a=tree;f=relatorio/tests;hb=HEAD -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: python-relatorio: where to put the test suite?
* Piotr Ożarowski: Re: python-relatorio: where to put the test suite? (Wed,
9 Jul 2014 13:33:17 +0200):
[Mathias Behrle, 2014-07-09]
relatorio has a test suite containing some images, documents and templates,
which according to FHS should belong under /usr/share.
Short question:
- does this justify a common package, from which linking to the
python2 and python3 package
- or is it just preferable to move the tests to docs (on dh_install)
if you have -doc binary package, then IMHO it's not that bad idea to
ship tests there as well (instead of providing -common package)
Note that .py files have to look exactly the same for 2.X and 3.X
- or is there a better solution, which I am currently not aware of?
if these tests are not that big, you can ship them in both packages, i.e. in
/usr/share/python{,3}-relatorio/tests (especially if 2to3 has to be used on
.py them)
The latter is the current state and the files are really not big. I just was
remembered by lintian:
python3-relatorio: image-file-in-usr-lib
usr/lib/python3/dist-packages/relatorio/tests/egg.jpg
which is the cause of my request.
Would that justify a lintian override? It would be indeed the simplest solution.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
Re: python-relatorio: where to put the test suite?
* Barry Warsaw: Re: python-relatorio: where to put the test suite? (Wed, 9
Jul 2014 09:13:17 -0400):
On Jul 09, 2014, at 12:55 PM, Mathias Behrle wrote:
relatorio has a test suite containing some images, documents and templates,
which according to FHS should belong under /usr/share.
Short question:
- does this justify a common package, from which linking to the
python2 and python3 package
- or is it just preferable to move the tests to docs (on dh_install)
- or is there a better solution, which I am currently not aware of?
Generally, I try to maintain whatever structure upstream has. E.g. if the
tests are shipped as a subpackage of the main package, I generally avoid
splitting those up. E.g. if you have python{,3}-foo providing the foo
package, and upstream ships foo/tests/*.py, I just leave them like that.
Sometimes they contain test data, but I won't move them elsewhere.
Ok. I think, this applies to my case. I will go then for a lintian override.
For various specific reasons, I'll sometimes split the tests out, but it's
usually more effort than it's worth IMO. It can make more sense though if the
tests are not shipped as a subpackage of the main package.
If you do split things up, you might want to add DEP-8 tests to make sure once
installed, everything works the way it should.
Thanks for your input, Piotr and Barry!
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
Re: [tryton-debian] python-relatorio: where to put the test suite?
* Piotr Ożarowski: Re: [tryton-debian] python-relatorio: where to put the
test suite? (Wed, 9 Jul 2014 15:41:30 +0200):
[Mathias Behrle, 2014-07-09]
if these tests are not that big, you can ship them in both packages, i.e.
in /usr/share/python{,3}-relatorio/tests (especially if 2to3 has to be
used on .py them)
The latter is the current state and the files are really not big. I just was
remembered by lintian:
python3-relatorio: image-file-in-usr-lib
usr/lib/python3/dist-packages/relatorio/tests/egg.jpg
which is the cause of my request.
Would that justify a lintian override? It would be indeed the simplest
solution.
no. Lintian is right and please do not override it if it's right.
You don't have to fix it, but please do not silence a valid warning.
PS note that I proposed to use
/usr/share/python{,3}-relatorio/tests and not
/usr/lib/python3/dist-packages/relatorio/tests/
Got it. Thanks for clarifying!
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
Re: Packaging of suds-jurko (was: suds)
* Jurko Gospodnetić: Re: Packaging of suds-jurko (was: suds) (Thu, 03 Jul 2014 11:32:28 +0200): Hi Jurko, On 3.7.2014. 0:07, Mathias Behrle wrote: My epydocs experience is *very* rusty. How hard would it be to covert the docs to Sphinx-consumable reST? Clearly, that's the state of the art in Python documentation these days. That was my initial thought, too. But then I supposed, that Jurko probably wanted to remain as near to the origin as possible in case his project would be re-merged. But at a second glance I think, that the migration of docs could also merged back as an improvement. Any thoughts, Jurko? I personally have no experience with epydoc and only some slight experience with Sphinx, and don't really care one way or the other at this point which one gets used. Since Sphinx is the de-facto standard today - I'd like to port the docs to Sphinx, but that can happen at a later time as well. Completely agreed. A plan that sounds reasonable to me: Phase 1. - get the current docs building as they stand now - whatever takes the least effort - doc sources infrastructure stored in the project's main version control repository - a build system that can generate the docs in html/pdf/txt/whatever format Phase 2. - generated release docs included in the published distributions, e.g. uploaded together with the release packages onto PyPI BitBucket - find out where the original suds project docs are kept, e.g. wiki at fedorahosted.org, generated code-level docs at http://jortel.fedorapeople.org/suds/doc - a distribution system that can keep an up-to-date version readily available in a public location, e.g. on https://readthedocs.org or the same site where the original project is hosted, possibly replacing the original project's docs Phase 3. - port the docs to Sphinx Since the original project already has publicly available docs, I'd be fine with replacing the original suds project after phase 2. If later phases are something that can be integrated 'at no cost' into earlier ones, I'm all for it, but I don't see it as a strict requirement. Some more thoughts on the scheduling: - phase 1 should not take much time, assuming the original project did have that automated somehow - if the original project had only a manually maintained WIKI as its basic docs - I'll have to see what to do about that as I really would not like a separate project setup like that - phase 2 might be tricky - I think readthedocs.org does not work with epydoc, but only sphinx so unless we manage to take over the original project's hosting locations it might be necessary to go the sphinx route earlier - essentially - more research is required :-) - as for phase 3 - the original project's autogenerated API docs would need to me transformed so they are generated using some sphinx plugin - suds does not have a terribly huge code-base so I guess any source code formatting/markup changes can be done in a full day or two I can do the legwork, go through the docs and update as needed but I'd rather not have such a potentially long-lasting task be a requirement for something with a deadline and constantly have that on my conscience. My day-job can easily take me away from suds for weeks at a time. :-) And I really really really would not like to have to go through all the docstrings and update their markup more than once. :-) My personal approach after a short glance to the existing documentation would be: - Release now after renaming the project without the docs (the existing documentation of suds is still existing on the web and should be roughly enough at this very moment). - Convert the available docs immediately to Sphinx, which AFAIS would mean - Get the wiki page from the fedora wiki [1], which is in mediawiki format, give it some love and convert it to sphinx. I attached the export of this page to this mail. - Convert the docstrings to Sphinx format - Here I found most interesting this sed script [2]. - or alternatively use a translation mechanism of Sphinx to use the current docstrings [3]. - Add the documentation, when ready, to the project and publish on read-the-docs. Personally I would prefer to convert at once and to not invest time in work, that will be superseeded anyway. This sequence of steps seems to me the most effective way to get things done. HTH, Mathias [1] https://fedorahosted.org/suds/wiki/Documentation [2] http://www.tomaz.me/2013/09/28/migrating-from-epydoc-to-sphinx-style-docstrings-using-sed-and-some-command-line-fu.html [3] http://stackoverflow.com/questions/10012741/automated-way-to-switch-from-epydocs-docstring-formatting-to-sphinx-docstring-f -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 [[PageOutline]] == OVERVIEW == The ''Suds'' web services client
Re: Packaging of suds-jurko (was: suds)
* Donald Stufft: Re: Packaging of suds-jurko (was: suds) (Tue, 1 Jul 2014 17:55:17 -0400): On Jul 1, 2014, at 5:41 PM, Barry Warsaw ba...@debian.org wrote: On Jul 01, 2014, at 01:10 PM, Mathias Behrle wrote: The first tests on suds-jurko are looking very promising. I built the package succesfully as a drop-in replacement for the current python-suds package. It builds correctly for python2 and python3 with all tests. I tested part of the functionality for python2, all was working well. The maintainer of suds-jurko is very active and responsive. Will a Python 3 compatible suds library allow us to make progress on #732644 without rewriting bts to use REST+JSON wink? 1) Can I drop in the suds-jurko fork into the current suds package as proposed by Jordan? Given that suds on PyPI hasn't been updated in almost 4 years, I think we can reasonably assume its upstream is defunct. We had a sort of analogous situation with setuptools, but the distribute and setuptools upstreams did eventually merge back together. A counter example might be oauth which was also abandoned upstream and for which a new upstream called oauthlib was released. However, in that case, the replacement was *not* API compatible, so it made sense to make it a different Debian package. I don't really have a strong opinion, as I can see both sides of the coin. You're *probably* safe just taking over the source package, but if you woke up tomorrow with an extra dose of paranoia, then you might favor a new source package, which also wouldn't be objectionable, albeit more work to transition dependencies. 2) If not 1) what would be the best alternative? In this case I would plan - a new python-suds-jurko package, conflicting with python-suds - filing bugs to rdepends to use the new package - removing the old package as soon as possible Yep. It's a bit ugly though (I don't like the -jurko blarg). Oh well, do what you think is right. -Barry *Puts on PyPI Admin Hat* Probably if suds-jurko or whatever is the unofficial “suds” that people should be using then there is a good chance that PyPI would be willing to transfer the name of suds to one of the forks. I’d have to talk to Richard to be sure about that but it’s potentially an option. That indeed would be really great. Jurko just had the same idea and it would be the cleanest solution. What steps should be done to achieve this? Is it enough to point Jurko to post a request on http://sourceforge.net/p/pypi/support-requests/ ? -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Packaging of suds-jurko (was: suds)
* Jurko Gospodnetić: Re: Re: Packaging of suds-jurko (was: suds) (Wed, 02 Jul 2014 12:15:35 +0200): Hi Jurko, [...] * I still have not taken over the original project's documentation and that is something I'd really like to do so I can update it with all the fixes/updates made to the library. If anyone has experience with epydocs and the toolchain used to generate the docs in the original suds project and is willing to assist, I can take a look at that this weekend. Sorry, no experience with epydocs on my side. * If the suds-jurko fork is to be made public as a part of the debian distribution, I'd really like to rename it so it does not have my name in it. That was an ok identifier when the project was just 'my silly little fork', but now it just does not seem right. * The name issue can be resolved by taking over the original project's name. However, I would really not like to do that before taking over the original project documentation. Ok, I will wait happily with the update of the python-suds package until it will be renamed on pypi. In case you didn't get the message from Donald, here is what to do as soon as you think to be prepared [1]. * The only thing that pops to mind at the moment expect for bugs inherited from the original project are the two missing suds.client.Client methods (last_sent() last_received()) Mathias already mentioned, but they are planned to be restored (and updated) anyway and this can be done fast, if required. I've been delaying this only because I'm using my time to design a proper test suite/environment for the project and would like to have tests for those function before reinstating them. * Any technical issues you encounter - just let me know and I'm sure we can find a suitable fix/workaround. As the project is still in the formal status of 'my silly little fork', we can be very flexible with the project's structure packaging. :-) Great to hear all that. Cheers, Mathias [1] https://lists.debian.org/debian-python/2014/07/msg8.html -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Packaging of suds-jurko
* Jurko Gospodnetić: Re: Packaging of suds-jurko (Wed, 02 Jul 2014 20:14:33 +0200): Hi Mathias. On 1.7.2014. 13:10, Mathias Behrle wrote: The first tests on suds-jurko are looking very promising. I built the package succesfully as a drop-in replacement for the current python-suds package. It builds correctly for python2 and python3 with all tests. I tested part of the functionality for python2, all was working well. The maintainer of suds-jurko is very active and responsive. Just wondering whether you used your own suds tests that you have laying around somewhere for debian, or if you simply ran the project's own test suite? I ran the projects test suite. More exactly, they are normally run by pybuild, the build system used for the suds package. The original project did not have a test suite at all and the one in my fork is growing and is being worked on but every time I touch suds I find more things that are missing, and my gut tells me that the tests are far from complete. :-) I suppose, that they can not be complete, but which test suite is...;) Well, to be perfectly honest, the original project did have a manual test suite, but it depended on lots of now defunct external web services or web services available only to the original developer. The does not depend on any external services, and I'm trying real hard to keep it that way. :-) Indeed those tests were disabled, because they connected to web services outside the builder, which is not allowed in Debian. And yes, please keep the tests of the package independent from services on the net, they would have to be disabled. Cheers, Mathias signature.asc Description: PGP signature
Re: Packaging of suds-jurko (was: suds)
* Barry Warsaw: Re: Packaging of suds-jurko (was: suds) (Wed, 2 Jul 2014 11:00:34 -0400): On Jul 02, 2014, at 04:16 PM, Mathias Behrle wrote: * I still have not taken over the original project's documentation and that is something I'd really like to do so I can update it with all the fixes/updates made to the library. If anyone has experience with epydocs and the toolchain used to generate the docs in the original suds project and is willing to assist, I can take a look at that this weekend. Sorry, no experience with epydocs on my side. My epydocs experience is *very* rusty. How hard would it be to covert the docs to Sphinx-consumable reST? Clearly, that's the state of the art in Python documentation these days. That was my initial thought, too. But then I supposed, that Jurko probably wanted to remain as near to the origin as possible in case his project would be re-merged. But at a second glance I think, that the migration of docs could also merged back as an improvement. Any thoughts, Jurko? signature.asc Description: PGP signature
Packaging of suds-jurko (was: suds)
* Jordan Metzmeier: Re: suds (was: favouring Python3 in the Debian policy) (Thu, 8 May 2014 10:22:47 -0500): Hi all, On Thu, May 8, 2014 at 4:11 AM, Mathias Behrle mathi...@m9s.biz wrote: * Jordan Metzmeier: Re: favouring Python3 in the Debian policy (Wed, 7 May 2014 21:55:20 -0500): Hello Jordan, The jurko fork was the one I was working with when attempting the port to suds. I never made it to testing under python3. [...] I consider debbugs to be broken, not suds. Thanks for your detailed explanations. Could you share, if you have any experiences with orginal suds compared to suds-furko (or any of the other forks mentionned by Barry)? I don't expect http://svn.fedorahosted.org/svn/suds/trunk to be revived [1] and of course it would be preferable to have an actively maintained version of suds in Debian. suds-furko seems to be the most appropriate candidate [2]. If no one raises his hands or objects, I will try to do some tests and file the ITP. My experience was no different than working with the original suds library. It might be better to replace our existing suds library with a fork rather than introduce the fork as a new package. The first tests on suds-jurko are looking very promising. I built the package succesfully as a drop-in replacement for the current python-suds package. It builds correctly for python2 and python3 with all tests. I tested part of the functionality for python2, all was working well. The maintainer of suds-jurko is very active and responsive. Now I would like to package suds-jurko as a replacemnt for suds and I want to ask, what is considered the best way (please indicate, if I should rather go to d-mentors, I am trying first here, because it is python and the thread started here.) According to the maintainer suds-jurko is almost fully API-compatible with original suds, where almost means the removal of two apparently obviusly unused methods (for the full message see below [1]). In case this should be a substantial obstacle, the maintainer offers to re-include those methods. So the first question, I couldn't solve from the docs I found: 1) Can I drop in the suds-jurko fork into the current suds package as proposed by Jordan? The license is unchanged, API compatibility seems to be guaranted. $ apt-cache rdepends python-suds python-suds Reverse Depends: python-ironic python-cinder vistrails python-vatnumber python-stdnum python-oslo.vmware python-psphere python-profitbricks-client python-trove python-nova python-nova python-ironic gtg congruity python-cinder 2) If not 1) what would be the best alternative? In this case I would plan - a new python-suds-jurko package, conflicting with python-suds - filing bugs to rdepends to use the new package - removing the old package as soon as possible Thanks for your input, Mathias [1] * Jurko Gospodnetić: Re: Preparing for packaging suds-jurko for Debian (Mon, 30 Jun 2014 21:44:43 +0200): After doing some successful tests, I want to replace the current suds package in Debian with your fork. To be well prepared I have two questions: 1) Is the current code base of suds-jurko completely API compatible with the code base from redhat? Can suds-jurko still be a drop-in replacement for suds? I really tried to keep it that way. :-) I know currently of only one place where this compatibility got broken 'accidentally' - the suds.client.Client last_sent() and last_received() methods have been removed (see issue #39 on BitBucket - https://bitbucket.org/jurko/suds/issue/39). They were never really cleanly implemented and the data they received could have been processed by some but not all registered plugins. Currently a relatively easy workaround is to register a custom plugin (a few lines of code) which will get all the same data at a precisely determined level of abstraction (e.g. raw XML bytes or XML document model constructed after suds parses the raw XML bytes, and such). In retrospect, perhaps they should not have been removed so abruptly, but at the time I found no mention of them anywhere in the source code, there were no tests related to them, no one on any of the mailing lists I contacted reported using them and they were getting in the way of some planned code cleanup. Anyway, I'm hoping to reimplement them back soon, but if you really need them 'at once', I guess their original implementation could be easily restored from the single commit that removed them. One reason why I'm still delaying with restoring them is that I'd like to find the time to prepare some tests for them first. There are other places where the public API got extended, e.g. extra options or the suds.store.DocumentStore class which can now be used to easily supply suds with locally stored resources so it does not need to fetch them over the network
suds (was: favouring Python3 in the Debian policy)
* Jordan Metzmeier: Re: favouring Python3 in the Debian policy (Wed, 7 May 2014 21:55:20 -0500): Hello Jordan, The jurko fork was the one I was working with when attempting the port to suds. I never made it to testing under python3. [...] I consider debbugs to be broken, not suds. Thanks for your detailed explanations. Could you share, if you have any experiences with orginal suds compared to suds-furko (or any of the other forks mentionned by Barry)? I don't expect http://svn.fedorahosted.org/svn/suds/trunk to be revived [1] and of course it would be preferable to have an actively maintained version of suds in Debian. suds-furko seems to be the most appropriate candidate [2]. If no one raises his hands or objects, I will try to do some tests and file the ITP. Cheers, Mathias [1] https://lists.fedoraproject.org/pipermail/suds/2013-July/002127.html [2] http://stackoverflow.com/questions/7739613/python-soap-client-use-suds-or-something-else -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Best practice: .egg-info with pybuild from git
* Piotr Ożarowski: Re: Best practice: .egg-info with pybuild from git (Thu, 21 Nov 2013 19:56:05 +0100): @Piotr: apologies for first not sending the mail to the group, but your mail address [Thomas Goirand, 2013-11-21] On 11/21/2013 08:28 PM, Mathias Behrle wrote: So finally I would appreciate any input on 1) Which is the preferred procedure to handle .egg-info directories together with building from git? 2) Is there a way to satisfy all common build tools as debuild, git-buildpackage, pbuilder, when running the build more than once? Thanks, Mathias Hi Mathias, Thanks for raising this important topic. I've seen all sorts of ways to fix this problem. What I found the most easy was to simply add: extend-diff-ignore = ^[^/]*[.]egg-info/ this line will tell dpkg-source to ignore these files but they're already ignored - pybuild removes them in clean target and dpkg-source ignores deleted files. It was also my impression, that this option can serve to silence the output of dpkg-source, but has no further effect with respect to this subject. BTW for complete silence the back slash at the end of the expression has to be removed. I think Mathias is asking about how to tell git that it should ignore these files as well. IMO you should ask upstream to not ship these files in git repo/tarballs or remove them in the first commit after each merge with upstream. Yes, the question basically was: How can I ensure safe double building and nevertheless return the build directory in the state it was before building. Removing .egg-info after each merge (cherry-pick) with upstream would be a solution, but a little bit ugly and error prone. So until now it turns out for me, that the best compromise is to - just remove .egg-info in clean is the best solution (no more needed with pybuild) - when building from git the repository to restore with git reset --hard after building - when building with git-buildpackage to use option --git-ignore-new -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Re: Best practice: exclude generated ‘foo.egg-info’ files from source and VCS (was: Best practice: .egg-info with pybuild from git)
* Ben Finney: Best practice: exclude generated ‘foo.egg-info’ files from source and VCS (was: Best practice: .egg-info with pybuild from git) (Fri, 22 Nov 2013 11:35:11 +1100): @Ben: apologies, first mail was sent to your mail address instead of the group Piotr Ożarowski pi...@debian.org writes: I think Mathias is asking about how to tell git that it should ignore these files as well. IMO you should ask upstream to not ship these files in git repo/tarballs or remove them in the first commit after each merge with upstream. Yes, the best course is to convince upstream to ship proper source tarballs, instead of bundling generated non-source files in the source tarball. To be more precise: I am packaging from release tarballs published on downloads.tryton.org resp. pypi [1]. Those tarballs are created with the standard command $ python setup.py sdist So upstream is shipping proper source tarballs (in a way;), the inclusion of generated non-source files comes from setuptools. It doesn't happen when using distutils, but I don't think I will have success, if I wanted upstream to change the working setup from the de-facto standard setuptools to distutils [2][3]. In the long term, the solution includes educating upstream not to put non-source files like the ‘foo.egg-info’ directory into the VCS. Files that need to be generated should be generated when creating the release tarballs, not tracked in VCS. Stated above, they are not in VCS, they are created when generating the release tarballs. Thanks to all for your input so far. [1] https://pypi.python.org/pypi?%3Aaction=searchterm=trytonsubmit=search [2] http://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-setuptools-and-distutils2 [3] http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/ -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
Best practice: .egg-info with pybuild from git
Hello Pythonistas,
I am just searching for some input/confirmation for the best practice with
respect to .egg-info provided in upstream tarballs.
My initial approach was based on the recommendations in the Python
Library Style Guide [1] and App Style Guide [2] to avoid evtl. double build
failures [3].
Using
override_dh_auto_clean:
dh_auto_clean
rm -rf build
rm -rf *.egg-info
works for the tested build methods debuild, pbuilder and git-buildpackage, but
has (when building from git) the disadvantage of leaving the git repository in
a different state.
As a workaround my sponsor made me think to use rather a renaming procedure
instead of deletion like
override_dh_auto_build:
mv $(PACKAGE_NAME).egg-info $(PACKAGE_NAME).hen-info
dh_auto_build
override_dh_auto_install:
dh_auto_install
rm -rf *.egg-info
mv $(PACKAGE_NAME).hen-info $(PACKAGE_NAME).egg-info
mv PKG-INFO.hen PKG-INFO
which also worked as long as using
dh ${@} --with python2
Now with the switch to enable dh_python3 and using
dh ${@} --with python2,python3 --buildsystem=pybuild
this doesn't work anymore with pbuilder failing with
make[1]: Entering directory `/tmp/buildd/python-sql-0.2'
mv python_sql.egg-info python_sql.hen-info
mv: der Aufruf von stat für „python_sql.egg-info“ ist nicht möglich: No such
file or directory
make[1]: *** [override_dh_auto_build] Fehler 1
because pybuild seems to remove .egg-info by itself (leaving the build dir in a
different state than it was before building).
So finally I would appreciate any input on
1) Which is the preferred procedure to handle .egg-info directories together
with building from git?
2) Is there a way to satisfy all common build tools as debuild,
git-buildpackage, pbuilder, when running the build more than once?
Thanks,
Mathias
[1] https://wiki.debian.org/Python/LibraryStyleGuide
[2] https://wiki.debian.org/Python/AppStyleGuide
[3] https://lists.debian.org/debian-python/2012/05/msg00039.html
signature.asc
Description: PGP signature
[Ping] Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP]
* Mathias Behrle: Bug#706957: RFS: tryton-modules-stock-lot/2.8.0-1 [ITP] (Mon, 6 May 2013 14:35:04 +0200): CCing specific audience debian-...@lists.debian.org and debian-python@lists.debian.org Dear mentors, could you please reconsider the RFS for this (and other) Tryton module(s)? Two weeks have passed without a response. The list of new packaged Tryton modules can be seen at [1] (ITPs) resp. [2] (RFSs). VCS for packaging can be found at [7]. They all add important new functionality to the Tryton framework. Especially this one (tryton-modules-stock-lot) is needed as dependency for the package gnuhealth [3] currently waiting in experimental. gnuhealth contains another set of Tryton modules providing the functionality of GNU Health, a free Health and Hospital Information System. All packages are packaged in the same way and they are free of lintian pedantic warnings (the one indicated being outdated [5]). So checking one is checking almost all of them, thus reducing the work load which could seem apparently high for 19 packages. Basically the complete suite of Tryton packages [6] is currently bug free, and I am doing my best to keep this state. I was already signalled to get DM Upload permissions for those new modules as I have already for the other packages. So sponsoring would be a one-shot and not a permanent task. I would appreciate a lot, if a sponsor could step up soon, because I would have preferred to upload the whole Tryton suite (which is still waiting from the freeze in experimental) together with the new modules at once to unstable. Thanks a lot for considering, Mathias [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=wnpp [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Atryton;dist=unstable;package=sponsorship-requests [3] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/gnuhealth/trunk/ [4] http://health.gnu.org/index.html [5] http://lists.debian.org/debian-lint-maint/2012/07/msg7.html [6] http://packages.debian.org/search?keywords=tryton [7] http://debian.tryton.org/gitweb/ Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package tryton-modules-stock-lot * Package name: tryton-modules-stock-lot Version : 2.8.0-1 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/2.8/ * License : GPL-3+ Section : python It builds those binary packages: tryton-modules-stock-lot - Tryton Application Platform (Stock Lot Module) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tryton-modules-stock-lot Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tryton-modules-stock-lot/tryton-modules-stock-lot_2.8.0-1.dsc More information about Tryton can be obtained from http://www.tryton.org Debian packaging for Tryton is hosted at http://debian.tryton.org Regards, Mathias Behrle -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
dh9: dh_python2 with dh_sphinxdoc: missing /usr/bin and /usr/lib in deb
Hi all,
I want to create a separate package tryton-modules-doc from the sphinx
documentation contained in tryton-server.
The packages are building without error, but in the final deb of
the server package (tryton-server) the files for /usr/bin and /usr/lib are
missing. Inspecting debian/tryton-server after the build shows still the
directory tmp containing those missing files, apparently not being moved to
debian/tryton-server/usr.
The build log doesn't show anything unusual.
Someone has a clue for me? Anything wrong with the usage of dh_sphinxdoc?
In case this qualifies as bug, should I report against package python or
python-sphinx?
diff --git a/debian/control b/debian/control
index bc60dcf..f7f6ae7 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,9 @@ Section: python
Priority: optional
Maintainer: Debian Tryton Maintainers maintain...@debian.tryton.org
Uploaders: Mathias Behrle mathi...@m9s.biz
-Build-Depends: debhelper (= 9), python (= 2.6.6-3~), python-setuptools
+Build-Depends:
+ debhelper (= 9), python (= 2.6.6-3~), python-setuptools,
+ python-sphinx (= 1.0.7+dfsg)
Standards-Version: 3.9.4
Homepage: http://www.tryton.org/
Vcs-Browser: http://debian.tryton.org/gitweb/?p=packages/tryton-server.git
@@ -28,3 +30,14 @@ Description: Tryton Application Platform (Server)
business solution.
.
This package contains the server.
+
+Package: tryton-server-doc
+Architecture: all
+Section: doc
+Depends: ${misc:Depends}, ${sphinxdoc:Depends}
+Description: Tryton Application Platform (Server Documentation)
+ Tryton is a high-level general purpose application platform written in Python
+ and using PostgreSQL as database engine. It is the core base of a complete
+ business solution.
+ .
+ This package contains the documentation of the server in HTML format.
diff --git a/debian/rules b/debian/rules
index d956c32..aeb14b2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,13 +1,17 @@
#!/usr/bin/make -f
%:
- dh ${@} --with python2
+ dh ${@} --with python2,sphinxdoc
override_dh_auto_clean:
dh_auto_clean
-
+ rm -rf build
rm -rf *.egg-info
+override_dh_installdocs:
+ sphinx-build doc build/html
+ dh_installdocs
+
override_dh_builddeb:
dh_builddeb -- -Zxz -z9
diff --git a/debian/tryton-server-doc.doc-base
b/debian/tryton-server-doc.doc-base new file mode 100644
index 000..527ccba
--- /dev/null
+++ b/debian/tryton-server-doc.doc-base
@@ -0,0 +1,10 @@
+Document: tryton-server
+Title: Tryton Server Documentation
+Author: Tryton Project
+Abstract: This is documentation of tryton-server, which includes models
+ documentation, extension documentation and API reference.
+Section: Programming/Python
+
+Format: HTML
+Index: /usr/share/doc/tryton-server-doc/html/index.html
+Files: /usr/share/doc/tryton-server-doc/html/*
diff --git a/debian/tryton-server-doc.docs b/debian/tryton-server-doc.docs
new file mode 100644
index 000..344fcaa
--- /dev/null
+++ b/debian/tryton-server-doc.docs
@@ -0,0 +1 @@
+build/html/
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
Re: dh9: dh_python2 with dh_sphinxdoc: missing /usr/bin and /usr/lib in deb
* Jakub Wilk: Re: dh9: dh_python2 with dh_sphinxdoc: missing /usr/bin and /usr/lib in deb (Mon, 13 May 2013 20:26:39 +0200): * Mathias Behrle mathi...@m9s.biz, 2013-05-13, 20:13: I want to create a separate package tryton-modules-doc from the sphinx documentation contained in tryton-server. The packages are building without error, but in the final deb of the server package (tryton-server) the files for /usr/bin and /usr/lib are missing. Inspecting debian/tryton-server after the build shows still the directory tmp containing those missing files, apparently not being moved to debian/tryton-server/usr. The build log doesn't show anything unusual. Quoting the dh_auto_install(1) manpage: Unless --destdir option is specified, the files are installed into debian/package/ if there is only one binary package. In the multiple binary package case, the files are instead installed into debian/tmp/, and should be moved from there to the appropriate package build directory using dh_install(1). You probably want to instruct dh_install which files belong to which packages, presumably by creating appropriate *.install files. Thanks a lot, Jakub! Adding debian/tmp/usr/*/usr to tryton-server.install did the thing. -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://m9s.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 signature.asc Description: PGP signature
