Re: nodoc solution HOWTO -- Avoid building Sphinx documentation on request (was: Bug#905750: RFS: elpy/1.23.0-1)
Nicholas D Steeves: > Hi Ben and readers of debian-mentors, > > Solution at bottom. > > [...] > > "export DEB_BUILD_PROFILES=nodoc ; gbp buildpackage" does not work, > although I expect "DEB_BUILD_PROFILES=nodoc ; export > DEB_BUILD_PROFILES ; gbp buildpackage" should. > Rather, I think there is a typo in changes. > --- > debian/changelog | 6 ++ > debian/control | 4 ++-- > debian/rules | 8 +++- > 3 files changed, 15 insertions(+), 3 deletions(-) > > [...] > diff --git a/debian/rules b/debian/rules > index a9d70b4..bd4c218 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -11,7 +11,13 @@ export LC_ALL > # docs are not generated without this override > override_dh_auto_build: > dh_auto_build > - PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator > +# support the nodoc build profile > +ifneq ($(filter nodocs,$(DEB_BUILD_PROFILES)),) ^^ nodocs != nodoc > + echo -e "\nnodoc build profile enabled, therefor not building docs.\n" > +else > + PYTHONPATH=. sphinx-build -N -bman docs/ build/man > PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info > makeinfo --no-split build/info/Elpy.texi -o build/info/elpy.info > cat NEWS.rst debian/local-var-snippet > build/NEWS > +endif > + > Thanks, ~Niels
Bug#906064: marked as done (RFS: fsdiff/0.5-1 [ITP])
Your message dated Wed, 05 Sep 2018 04:20:37 + with message-id and subject line closing RFS: fsdiff/0.5-1 [ITP] has caused the Debian Bug report #906064, regarding RFS: fsdiff/0.5-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 906064: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906064 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "fsdiff" * Package name: fsdiff Version : 0.3.1-1 Upstream Author : Ioannis Valasakis * URL : https://github.com/wizofe/fsdiff * License : GNU GPL v2.0 Section : devel It builds those binary packages: fsdiff - A simple tool for bit to bit comparison To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fsdiff Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fsdiff/fsdiff_0.3.1-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: fsdiff (0.3.1-1) unstable; urgency=low * Add debian packaging * Remove unused Python files * Fix colorama package import bug -- Ioannis Valasakis Mon, 13 Aug 2018 01:28:10 + Regards, Ioannis Valasakis -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Package fsdiff has been removed from mentors.--- End Message ---
Re: nodoc solution HOWTO -- Avoid building Sphinx documentation on request (was: Bug#905750: RFS: elpy/1.23.0-1)
Hi Ben and readers of debian-mentors, Solution at bottom. On Sat, Sep 01, 2018 at 08:26:07PM -0400, Nicholas D Steeves wrote: > On Fri, Aug 10, 2018 at 06:02:14AM +1000, Ben Finney wrote: > > Chris Lamb writes: > > > > > * You should probably avoid building the documentation too if the > > >nodocs build profile is enabled. > > > > For packages from PyPI which have documentation detectable by > > ‘dh_sphinxdoc’, does this (avoid building the documentation if the > > “nodocs” build profile is enabled) just work by default? Or do we need > > some specific change to the Debian package? Could you give me an example of such a package? I'd be happy to investigate. > I also wonder about this :-) Unfortunately, in the case of Elpy, > dh_sphinxdoc does not find the documentation, and specifying a subdir > only limits the search for documentation to that dir.: >dh_sphinxdoc -O--buildsystem=pybuild > dh_sphinxdoc: Sphinx documentation not found > > > Is there generic Debian package maintainer advice that can be given – > > specific things to put in ‘/debian/rules’, etc. – to let “nodocs” work > > as designed? See solution at bottom. Where would be a convenient location for such documentation? Convenient, because convenience helps with adoption ;-) > Yes, this would be very much appreciated! > > I followed a Debian Python Team wiki page on the topic and am > currently using the following in debian/rules: > > override_dh_auto_build: > > dh_auto_build > PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator > PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info > makeinfo --no-split build/info/Elpy.texi -o build/info/elpy.info > > It was trivially easy to figure out how to build info pages, based on > the manpage generator example. > > I imagine something like wrapping the relevant sections of the > overridden dh_auto_build with a conditional check would do the trick, > but I haven't yet found an example, nor documentation of "nodocs". > eg: > > override_dh_auto_build: > > dh_auto_build > ifeq ($(nodocs),"YET_UNKNOWN_VALUE_SHOULD_EVAL_FALSE_FOR_NORMAL_BUILD") > PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator > PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info > makeinfo --no-split build/info/Elpy.texi -o build/info/elpy.info > endif > > The trouble is there are no booleans in Makefiles, and an undefined > variable doesn't eval to nil like in LISPs. So I don't know how to > proceed. I trivially adapted the--I think it was stage 1 bootstrapping--example from the BuildProfiles specification page. Another caveat I encountered was that it isn't documented that these changes should be tested with "DEB_BUILD_PROFILES=nodoc gbp buildpackage", or builder-of-choice instead of "gbp buildpackage", and that the builder would pass through the envvar to dpkg-buildpackage. "export DEB_BUILD_PROFILES=nodoc ; gbp buildpackage" does not work, although I expect "DEB_BUILD_PROFILES=nodoc ; export DEB_BUILD_PROFILES ; gbp buildpackage" should. --- debian/changelog | 6 ++ debian/control | 4 ++-- debian/rules | 8 +++- 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index b62b11d..4f74bab 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +elpy (1.24.0-2) UNRELEASED; urgency=medium + + * Support 'nodoc' build profile. + + -- Nicholas D Steeves Tue, 04 Sep 2018 18:10:11 -0400 + elpy (1.24.0-1) unstable; urgency=medium * New upstream version. diff --git a/debian/control b/debian/control index 5bd04d3..f130ed3 100644 --- a/debian/control +++ b/debian/control @@ -27,8 +27,8 @@ Build-Depends: debhelper (>= 11~) , python3-mock , python3-nose , python3-pip - , python3-sphinx - , texinfo + , python3-sphinx + , texinfo Standards-Version: 4.2.1 Vcs-Browser: https://salsa.debian.org/emacsen-team/elpy Vcs-Git: https://salsa.debian.org/emacsen-team/elpy.git diff --git a/debian/rules b/debian/rules index a9d70b4..bd4c218 100755 --- a/debian/rules +++ b/debian/rules @@ -11,7 +11,13 @@ export LC_ALL # docs are not generated without this override override_dh_auto_build: dh_auto_build - PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator +# support the nodoc build profile +ifneq ($(filter nodocs,$(DEB_BUILD_PROFILES)),) + echo -e "\nnodoc build profile enabled, therefor not building docs.\n" +else + PYTHONPATH=. sphinx-build -N -bman docs/ build/man PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info makeinfo --no-split build/info/Elpy.texi -o
Bug#907914: RFS: elpy/1.24.0-1
Hi Chris, On Tue, Sep 04, 2018 at 09:57:10AM +0100, Chris Lamb wrote: > Nicholas, > > > To address the last TODO list submitted for this package: I have not > > yet pursued changes to lintian about the Informational message on > > "wrong section". I will ask an Emacsen and Policy team member about > > where the appropriate place to pursue this issue would be, because I > > believe lintian is currently doing the right thing in providing > > Informational-level nagging, as if to say "Are you really sure the > > declared section is more appropriate?" Yes, I am certain that section > > "devel" is most appropriate for an IDE addon ;-) > > If it's an genuine exception that just happens to trigger the package regex, > then a lintian override could be justified. Aha! Yes, I agree, that sounds like the best way forward. WRT to "genuine exception" shouldn't someone ACK the official section change in Bug #900212 before I remove the lint/reminder with an override? > 11 # docs are not generated without this override > 12 override_dh_auto_build: > 13 dh_auto_build > 14 PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage > generator > > … this does not obey 'nodoc' build profile. Oops, sorry about that. The 'nodoc' build profile will be supported in the next release, but I will wait for next upstream release unless a pressing issue emerges, and failing that will upload a -2 revision in November. https://salsa.debian.org/emacsen-team/elpy/commit/223849582fbc64378b81875aa0daa10454c9f736 Cheers, Nicholas signature.asc Description: PGP signature
Bug#907826: RFS: gnomint/1.3.0-1 [QA] [RC]
Hello Yavor Doganov, Thanks for working on improving this package. Please see comments below (inline). On Sun, Sep 02, 2018 at 07:41:18PM +0300, Yavor Doganov wrote: [...] > I'm looking for a sponsor for a QA upload of "gnomint". > > * Package name: gnomint >Version : 1.3.0-1 [...] > Changes since the last upload: > > * QA upload. > * New upstream release. > * debian/compat: Set to 11. > * debian/control: Run wrap-and-sort -ast. > (Build-Depends): Bump debhelper requirement to match the compat level. > Remove autotools-dev and libgconf2-dev. > (Standards-Version): Claim compliance with 4.2.1 as of this release. > * debian/rules: Enable all hardening. Remove --with autotools_dev. > (override_dh_auto_install): Remove gconf schemas stuff. > * debian/patches/682432.patch: Refresh. > * debian/patches/02-cflags.patch: Remove configure hunk; refresh and > remove -Werror. Fix typo in the patch description. > * debian/patches/01-ldd.patch: > * debian/patches/10_gnutlsv3.diff: Delete, fixed upstream. > * debian/patches/fix-autoreconf.patch: New, fix autoreconf failure. > * debian/patches/gsettings-port.patch: New, migrate from GConf to > GSettings (Closes: #885817). I believe the switch to GSettings also > closes: #631768 which was probably due to the fact that GConf does not > apply changes atomically. This patch seems to include a conversion file to migrate the existing data/settings over from gconf2 to gsettings database, however the 'gsettings-data-convert' tool is part of the 'gconf2' package but there's no dependency from gnomint against gconf2 so the conversion won't happen unless the user already has gconf2 installed (which is becoming less and less likely). With gsettings migration I guess you feel it's unwelcome to have a dependency on gconf2 remaining in buster, but for data conversion the dependency needs to remain until gsettings conversion has shipped in one stable debian release (as a minimum). > * debian/patches/export-private-key-crash.patch: New, fix crash when > exporting the private key (Closes: #855200). Thanks to Karl E. > Jorgensen for the report. > * debian/patches/desktop-file.patch: New, fix some lintian complaints. > * debian/patches/spelling-errors.patch: New, self-explanatory. > * debian/patches/series: Update. > * debian/watch: New file. > * debian/pixmaps/gnomint.xpm: > * debian/gnomint.menu: > * debian/gnomint.install: Delete. I guess you mean 'Delete' applies to all three above? Maybe would have been better to write them under the same bullet point. (Also I'm not sure about separating the changelog on a per-file basis, rather than on a per-change basis but I guess that's related to personal taste and different people do it differently.) > * debian/copyright: Declare format. > Regards, Andreas Henriksson
Bug#907986: marked as done (RFS: simple-scan/3.30.0-1 RC)
Your message dated Tue, 4 Sep 2018 22:17:30 +0200 with message-id <20180904201730.z5z3uugepthyt...@fatal.se> and subject line Re: RFS: simple-scan/3.30.0-1 RC has caused the Debian Bug report #907986, regarding RFS: simple-scan/3.30.0-1 RC to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 907986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907986 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "simple-scan" Package name: simple-scan Version : 3.30.0-1 Upstream Author : Robert Ancell URL : https://gitlab.gnome.org/GNOME/simple-scan License : GPL-3+ Section : gnome It builds those binary packages: simple-scan - Simple Scanning Utility To access further information about this package, please visit the following URL: https://mentors.debian.net/package/simple-scan Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/simple-scan/simple-scan_3.30.0-1.dsc and/or git https://jff.email/cgit/simple-scan.git?h=release%2Fdebian%2F3.30.0-1 Changes since the last upload: * New upstream release (Closes: #907932). * Declare compliance with Debian Policy 4.2.1 (No changes needed). Regards, Jörg Frings-Fürst - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluO4h8ACgkQCfifPIyh 0l0p2hAAr7b81QEAWzPqqG+zoHX0/FQCG5uoF6CMfASYoSt0u9Ryw4RT16zVvVoc pX5+cJ+dxvHij/T090qmWgTVJzg4YJW6EFzCxux/bNtwBJz5Aw19sbzFjCjSYMlS s6tZ+HEEAYpkLG1BNBELkneDWvs4gt11mamiFgysYh7Om6ujnUjXapeVDwEzBCJa WD1wXMOoheqqYKTmm1+gwCLwxtYm68uQfIvGHu1yznVmdRx5yWTM8C/tpVfXmxvh mfB8cONK633PeJVGxtiWvgzufAjEDMlyxoQFRAZLslaQqc6px/wgNDo9Vj1rgOF2 7MrdNvnLZDxt1Yhzq19w1rYGO6ZkzrFv5ASqJQoab3ugT16XM/asSVxlyCma7pH9 3PS2uvl6Yp0I8nm+ELzhFVx1KKnvpFuQnnf95uW76qhuVh5bKvQe7iy/KMjeDLyP mq3bVLM11lAo/F6cAnDggX/cW9YJ4KHWYLEPeb7EmrcvKchhbBwMKtmqtnLpykRS yw6IsFkzm2yu2E4Tvy0aD8dqSosYa2TTYJkPAHggOHXrx0GfCsS66jM9L9BiYztL wniIx6r7G0IHYfm6FkoUA7b3xC27gbvNrlBsc9zm3ABiATIDE/DFgLkQKkqX+Hzd Ig0sw2hcNlbKeDLhwNAYdGeeOZ82uWkXRAv7Y/z4lMog8xtH9CU= =eL2l -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On Tue, Sep 04, 2018 at 09:50:55PM +0200, Jörg Frings-Fürst wrote: [...] > I am looking for a sponsor for my package "simple-scan" > >Package name: simple-scan >Version : 3.30.0-1 [...] Uploaded. Regards, Andreas Henriksson--- End Message ---
Bug#907986: RFS: simple-scan/3.30.0-1 RC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "simple-scan" Package name: simple-scan Version : 3.30.0-1 Upstream Author : Robert Ancell URL : https://gitlab.gnome.org/GNOME/simple-scan License : GPL-3+ Section : gnome It builds those binary packages: simple-scan - Simple Scanning Utility To access further information about this package, please visit the following URL: https://mentors.debian.net/package/simple-scan Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/simple-scan/simple-scan_3.30.0-1.dsc and/or git https://jff.email/cgit/simple-scan.git?h=release%2Fdebian%2F3.30.0-1 Changes since the last upload: * New upstream release (Closes: #907932). * Declare compliance with Debian Policy 4.2.1 (No changes needed). Regards, Jörg Frings-Fürst - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluO4h8ACgkQCfifPIyh 0l0p2hAAr7b81QEAWzPqqG+zoHX0/FQCG5uoF6CMfASYoSt0u9Ryw4RT16zVvVoc pX5+cJ+dxvHij/T090qmWgTVJzg4YJW6EFzCxux/bNtwBJz5Aw19sbzFjCjSYMlS s6tZ+HEEAYpkLG1BNBELkneDWvs4gt11mamiFgysYh7Om6ujnUjXapeVDwEzBCJa WD1wXMOoheqqYKTmm1+gwCLwxtYm68uQfIvGHu1yznVmdRx5yWTM8C/tpVfXmxvh mfB8cONK633PeJVGxtiWvgzufAjEDMlyxoQFRAZLslaQqc6px/wgNDo9Vj1rgOF2 7MrdNvnLZDxt1Yhzq19w1rYGO6ZkzrFv5ASqJQoab3ugT16XM/asSVxlyCma7pH9 3PS2uvl6Yp0I8nm+ELzhFVx1KKnvpFuQnnf95uW76qhuVh5bKvQe7iy/KMjeDLyP mq3bVLM11lAo/F6cAnDggX/cW9YJ4KHWYLEPeb7EmrcvKchhbBwMKtmqtnLpykRS yw6IsFkzm2yu2E4Tvy0aD8dqSosYa2TTYJkPAHggOHXrx0GfCsS66jM9L9BiYztL wniIx6r7G0IHYfm6FkoUA7b3xC27gbvNrlBsc9zm3ABiATIDE/DFgLkQKkqX+Hzd Ig0sw2hcNlbKeDLhwNAYdGeeOZ82uWkXRAv7Y/z4lMog8xtH9CU= =eL2l -END PGP SIGNATURE-
Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code
control: retitle -1 RFS: tensorflow/1.10.1+dfsg-A1 [ITP] control: tag -1 -moreinfo Hello science team and mentors, I did a right choice to write the python+ninja build system from scratch (I call this build system TF-Shogun in the source code). Now I started to sort out any possible FTBFS with dom/PPA/others. https://salsa.debian.org/science-team/tensorflow Currently I can build it manually on my daily Debian experimental system (amd64) and another unclean chroot (amd64). However I'm still not sure whether the other can build it successfully like I do. Any FTBFS report will be appreciated and patches for fixing FTBFS or improving the build system will be much appreciated. Following is the lastest todo list before the first upload. - [ ] Does it FTBFS on amd64 and ppc64el? - [ ] is the resulting libtensorflow.so.1.10 correct and working? - [ ] write autopkgtest with some mini C/C++ programs. - [ ] find out the way to build tests (googletest). - [ ] make sure libtensorflow/amd64 is linked against libmkldnn - [ ] findout how to build and run the tests. - [ ] upload to experimental. And this list is not growing, really.
Bug#907914: marked as done (RFS: elpy/1.24.0-1)
Your message dated Tue, 04 Sep 2018 10:21:38 +
with message-id
and subject line closing RFS: elpy/1.24.0-1
has caused the Debian Bug report #907914,
regarding RFS: elpy/1.24.0-1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
907914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907914
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
Hi Chris, and dear mentors,
I am looking for a sponsor for my package "elpy".
Package name: elpy
Version : 1.24.0-1
URL : https://github.com/jorgenschaefer/elpy
License : GPL-3+
Section : devel
To address the last TODO list submitted for this package: I have not
yet pursued changes to lintian about the Informational message on
"wrong section". I will ask an Emacsen and Policy team member about
where the appropriate place to pursue this issue would be, because I
believe lintian is currently doing the right thing in providing
Informational-level nagging, as if to say "Are you really sure the
declared section is more appropriate?" Yes, I am certain that section
"devel" is most appropriate for an IDE addon ;-)
It builds this binary package:
elpa-elpy - Emacs Python Development Environment
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/elpy
Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.24.0-1.dsc
Changes since the last upload:
elpy (1.24.0-1) unstable; urgency=medium
* New upstream version.
* Revert "Compress README.rst with gzip before installing" because
README.rst is only 2.8k and dh_compress already does the right thing
automatically; that is to say, README.rst is not "larger than 4k in
size" (dh_compress(1)) and should not be compressed.
* Exclusively use Python 3 dependencies and configure the use of
/usr/bin/python3 by default. (Closes: #899212)
* debian/README.Debian: Document how Python 2 support is not enabled
in this Debian package.
* debian/debian-autoloads.el:
- Add Debian-specific configuration to default to using Python 3.
- Document this customisation in README.Debian along with instructions
on how to revert this when moving between Python 2 and Python 3
virtualenvs.
- Additionally unset Elpy's custom PYTHONPATH, which is not needed in
packages that use dh-python. Previously Elpy unnecessarily searched
site-lisp/elpa/elpy-1.23.0 for its associated Python modules.
* debian/control:
- Drop python2 dependencies which are no longer needed
for self-tests to pass.
- Put ELPA build-dep section before Python one (more alphabetical).
- Move python3-sphinx build dependency to the section for documentation.
- Add python3-jupyter-console to Suggests. The upstream Elpy project
recommends using Jupyter console for interactive Python.
- Rely on ${elpa:Depends} and drop explicitly declared ones in bin:pkg.
- Rely on ${python3:Depends} to generate dependency on python3-flake8.
- Add build and runtime dependency on flake8, which provides
/usr/bin/flake8. This wrapper script is still used in various places,
and it is part of the flake8 package provided by PyPI/pip.
* Declare Standards-Version: 4.2.1. (No additional changes required)
-- Nicholas D Steeves Mon, 03 Sep 2018 20:08:24 -0400
elpy (1.23.0-1) unstable; urgency=medium
Regards,
Nicholas D Steeves
--- End Message ---
--- Begin Message ---
Package elpy has been removed from mentors.--- End Message ---
Re: RFS: python-scp/0.11.0-1 [ITA]
Awesome, thanks! El mar., 4 de sep. de 2018 a la(s) 07:14, Andrej Shadura (and...@shadura.me) escribió: > On 3 September 2018 at 16:37, eamanu15 wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "python-scp". > > After a bit of fiddling with the changelog, uploaded. > > -- > Cheers, > Andrej > -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Re: RFS: python-scp/0.11.0-1 [ITA]
On 3 September 2018 at 16:37, eamanu15 wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "python-scp". After a bit of fiddling with the changelog, uploaded. -- Cheers, Andrej
Bug#907914: RFS: elpy/1.24.0-1
Nicholas, > To address the last TODO list submitted for this package: I have not > yet pursued changes to lintian about the Informational message on > "wrong section". I will ask an Emacsen and Policy team member about > where the appropriate place to pursue this issue would be, because I > believe lintian is currently doing the right thing in providing > Informational-level nagging, as if to say "Are you really sure the > declared section is more appropriate?" Yes, I am certain that section > "devel" is most appropriate for an IDE addon ;-) If it's an genuine exception that just happens to trigger the package regex, then a lintian override could be justified. 11 # docs are not generated without this override 12 override_dh_auto_build: 13 dh_auto_build 14 PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator … this does not obey 'nodoc' build profile. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#907838: RFS: 2 pkgs once part of emacs-goodies-el: bm-el/201808-1, mutt-alias-el/1.5-1
Nicholas, > If you would still prefer that I not reply post-RFS, please let me > know and I'll stop :-) I don't have any problem with replies per se, I'm just getting the impression from the verbosity of your responses that extensive rationalisations dissecting your thought process that led to something is required. > What approach would you prefer for future RFSs? No strong preference. Staying with the team norm seems more sensible. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
