Re: Sphinx 1.3 in Debian experimental
On May 03, 2015, at 03:18 PM, Dmitry Shachnev wrote: >I have finally managed to finalize Sphinx 1.3 upload for experimental. Thanks! I just added the Python 3.5 compatibility patch from upstream github to sphinx's svn. >Also, if someone is interested in helping me to maintain Sphinx is Debian, >that is welcome. I have a task list [2] which may be a good starting >point. Especially appreciated is help with dh_sphinxdoc, because it's >written in Perl which I don't speak well :) My Perl is pretty rusty, but I am happy to help out with Sphinx as time allows. I just added a patch from upstream to support Python 3.5, which might not help Debian right now, but is useful for my 3.5 rebuild test. On May 06, 2015, at 07:55 PM, Yaroslav Halchenko wrote: >I am not sure if you got time to do rebuild but meanwhile I ran it on my >box... runs serially and box is getting aged so it is still running but here >is a current summary of things: >http://www.onerussian.com/tmp/sphinx_1.3.1-1_amd64.testrdepends.debian-sid.summary >first column is for a build with prev version of sphinx in sid and the last >one with status of build and pointer to log if failed > >so -- there is quite a few of new FTBFS. I will report more whenever it is >done Odd. I tried rebuilding all the flufl.* packages with a sphinx built from svn; they're listed as failing on your page, but they all passed just fine for me locally. I didn't see any clickable links in the summary you posted so I can't tell what the failures might have been. Can you provide details or do another rebuild? Cheers, -Barry pgp80kRo7ujca.pgp Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
Hi Barry, On Mon, 29 Jun 2015 11:23:36 -0400, Barry Warsaw wrote: > My Perl is pretty rusty, but I am happy to help out with Sphinx as time > allows. Appreciated! > I just added a patch from upstream to support Python 3.5, which might > not help Debian right now, but is useful for my 3.5 rebuild test. Thanks, I will now do a new experimental upload with this patch. > Odd. I tried rebuilding all the flufl.* packages with a sphinx built from > svn; they're listed as failing on your page, but they all passed just fine for > me locally. I didn't see any clickable links in the summary you posted so I > can't tell what the failures might have been. Can you provide details or do > another rebuild? Your packages were failing with 1.3.1-1, but are not failing with svn build because I fixed the issue :) FWIW I have went through Yaroslav's logs and filed bugs for most of the failing packages [1], but there are still some harder packages which I don't have time to properly test/investigate. [1]: http://deb.li/sphinx13 -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
Hi, would you mind talking to the build reproducible folks to understand how to make sphinx generating reproducible builds by default (instead of patching all the software using it)? On Mon, Jun 29, 2015 at 1:06 PM, Dmitry Shachnev wrote: > Hi Barry, > > On Mon, 29 Jun 2015 11:23:36 -0400, Barry Warsaw wrote: >> My Perl is pretty rusty, but I am happy to help out with Sphinx as time >> allows. > > Appreciated! > >> I just added a patch from upstream to support Python 3.5, which might >> not help Debian right now, but is useful for my 3.5 rebuild test. > > Thanks, I will now do a new experimental upload with this patch. > >> Odd. I tried rebuilding all the flufl.* packages with a sphinx built from >> svn; they're listed as failing on your page, but they all passed just fine >> for >> me locally. I didn't see any clickable links in the summary you posted so I >> can't tell what the failures might have been. Can you provide details or do >> another rebuild? > > Your packages were failing with 1.3.1-1, but are not failing with svn build > because I fixed the issue :) > > FWIW I have went through Yaroslav's logs and filed bugs for most of the > failing packages [1], but there are still some harder packages which I don't > have time to properly test/investigate. > > [1]: http://deb.li/sphinx13 > > -- > Dmitry Shachnev -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxxdtrmy+n9_4svhqu3zja5jn53uwa-wz8gi0u9heo4...@mail.gmail.com
Re: Sphinx 1.3 in Debian experimental
On Jun 29, 2015, at 08:06 PM, Dmitry Shachnev wrote: >Your packages were failing with 1.3.1-1, but are not failing with svn build >because I fixed the issue :) Ah, I guess we need an ITP for snowballstemmer . >FWIW I have went through Yaroslav's logs and filed bugs for most of the >failing packages [1], but there are still some harder packages which I don't >have time to properly test/investigate. > >[1]: http://deb.li/sphinx13 I don't regularly touch any of those packages, but I'll keep an eye on them if I ever do. Thanks for the great work on Sphinx! Cheers, -Barry pgptHFB1rUBRo.pgp Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
Hi Sandro, On Mon, 29 Jun 2015 13:12:33 -0400, Sandro Tosi wrote: > would you mind talking to the build reproducible folks to understand > how to make sphinx generating reproducible builds by default (instead > of patching all the software using it)? Most of the issues are already fixed in 1.3 (i.e. I applied a patch from #776443 there). If there is something else, please let me know. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
that's great news! I just recently (like end of last week) received a patch for basemap to address dates in the doc, and it seemed like your effort and their were not in sync. Might just be enough to give them a heads up so they dont waste more time in fixing docs when a the new release of sphinx will do it once and for all On Mon, Jun 29, 2015 at 1:33 PM, Dmitry Shachnev wrote: > Hi Sandro, > > On Mon, 29 Jun 2015 13:12:33 -0400, Sandro Tosi wrote: >> would you mind talking to the build reproducible folks to understand >> how to make sphinx generating reproducible builds by default (instead >> of patching all the software using it)? > > Most of the issues are already fixed in 1.3 (i.e. I applied a patch > from #776443 there). If there is something else, please let me know. > > -- > Dmitry Shachnev -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAB4XWXx5wNKOuO6CHTFnP=kerbk8=0e-ec2musx3rfzwrwq...@mail.gmail.com
Re: Sphinx 1.3 in Debian experimental
Hi Sandro, On Mon, 29 Jun 2015 14:08:40 -0400, Sandro Tosi wrote: > that's great news! I just recently (like end of last week) received a > patch for basemap to address dates in the doc, and it seemed like your > effort and their were not in sync. Looking at the patch in #790235, that is a different issue. It happens because basemap uses |today| in a couple of files, namely: http://sources.debian.net/src/basemap/1.0.7+dfsg-1/doc/users/index.rst/#L8 http://sources.debian.net/src/basemap/1.0.7+dfsg-1/doc/api/index.rst/#L8 I am not sure if I can change everything in Sphinx for that. Juan's patches set |today| to a value based on dpkg-parsechangelog output, but that is obviously unacceptable for upstream Sphinx, and carrying that as a Debian-specific patch will be an ugly hack. In your particular case (and probably other ones), I think it'll be much easier to patch out uses of |today| than to apply Juan's hack. > Might just be enough to give them a heads up so they dont waste more time > in fixing docs when a the new release of sphinx will do it once and for all The patch in Sphinx 1.3 was written by Chris Lamb, who is one of the most active participants of Debian reproducible builds effort. So I don't think there can be some issue with synchronization here. Also, as your example demonstrates, Sphinx 1.3 won't "do it once and for all". -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
On Mon, Jun 29, 2015 at 2:41 PM, Dmitry Shachnev wrote: > Hi Sandro, > > On Mon, 29 Jun 2015 14:08:40 -0400, Sandro Tosi wrote: >> that's great news! I just recently (like end of last week) received a >> patch for basemap to address dates in the doc, and it seemed like your >> effort and their were not in sync. > > Looking at the patch in #790235, that is a different issue. > > It happens because basemap uses |today| in a couple of files, namely: > > http://sources.debian.net/src/basemap/1.0.7+dfsg-1/doc/users/index.rst/#L8 > http://sources.debian.net/src/basemap/1.0.7+dfsg-1/doc/api/index.rst/#L8 > > I am not sure if I can change everything in Sphinx for that. > Juan's patches set |today| to a value based on dpkg-parsechangelog output, > but that is obviously unacceptable for upstream Sphinx, and carrying that > as a Debian-specific patch will be an ugly hack. > > In your particular case (and probably other ones), I think it'll be much > easier to patch out uses of |today| than to apply Juan's hack. well that requires to carry the patch in all the packages using |today| instead of adapt sphinx to what Debian wants to achieve (reproducible build) in the place that makes more sense: the tool generating the doc. YMMV tho >> Might just be enough to give them a heads up so they dont waste more time >> in fixing docs when a the new release of sphinx will do it once and for all > > The patch in Sphinx 1.3 was written by Chris Lamb, who is one of the most > active participants of Debian reproducible builds effort. So I don't think > there can be some issue with synchronization here. > > Also, as your example demonstrates, Sphinx 1.3 won't "do it once and for all". > > -- > Dmitry Shachnev -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxyeafv8eh_cobfqdg+c5sb_6djnk52ylp7sj-lhsnf...@mail.gmail.com
Re: Sphinx 1.3 in Debian experimental
Hi Sandro, On Mon, 29 Jun 2015 15:11:00 -0400, Sandro Tosi wrote: > well that requires to carry the patch in all the packages using > |today| instead of adapt sphinx to what Debian wants to achieve > (reproducible build) in the place that makes more sense: the tool > generating the doc. YMMV tho According to codesearch, only 59 packages out of 608 using Sphinx have |today| somewhere in their .rst files [1]. And I believe most of those 59 already have bugs filed for them. |today| is for Sphinx the same as __DATE__ is for a C compiler. You do not suggest to patch gcc to remove support for __DATE__, do you? Anyway, if you provide a suggestion for how to fix this on Sphinx side (not *so* hackish as parsing d/changelog), I will look at it. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
On Mon, 29 Jun 2015 22:26:22 +0300, Dmitry Shachnev wrote: > According to codesearch, only 59 packages out of 608 using Sphinx have > |today| somewhere in their .rst files [1]. Forgotten reference: [1] queries I used: \|today\| path:.*\.rst# |today| in source files (not in conf.py template) python3?-sphinx path:debian/control # build-depends on python-sphinx or python3-sphinx -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Re: Sphinx 1.3 in Debian experimental
I dont have a patch for sphinx to fix that, but what I say is that patching 59 packages to remove |today| instead of changing sphinx /somehow/ is a waste of resources. On Mon, Jun 29, 2015 at 3:26 PM, Dmitry Shachnev wrote: > Hi Sandro, > > On Mon, 29 Jun 2015 15:11:00 -0400, Sandro Tosi wrote: >> well that requires to carry the patch in all the packages using >> |today| instead of adapt sphinx to what Debian wants to achieve >> (reproducible build) in the place that makes more sense: the tool >> generating the doc. YMMV tho > > According to codesearch, only 59 packages out of 608 using Sphinx have > |today| somewhere in their .rst files [1]. And I believe most of those 59 > already have bugs filed for them. > > |today| is for Sphinx the same as __DATE__ is for a C compiler. You do not > suggest to patch gcc to remove support for __DATE__, do you? > > Anyway, if you provide a suggestion for how to fix this on Sphinx side > (not *so* hackish as parsing d/changelog), I will look at it. > > -- > Dmitry Shachnev -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxzqnbltisbrd2vbjzozwuwtwgzcazhvnumfo6yx-8f...@mail.gmail.com
Re: Sphinx 1.3 in Debian experimental
On Jun 29, 2015, at 04:02 PM, Sandro Tosi wrote:
>I dont have a patch for sphinx to fix that, but what I say is that
>patching 59 packages to remove |today| instead of changing sphinx
>/somehow/ is a waste of resources.
Maybe upstream would accept a patch similar to what I've done before. It
could map |today| to the value of an environment variable, if it's set.
E.g. something like SPHINX_TODAY. Then pybuild, dh_python{2,3}, or some other
infrastructure piece could set that to the parsed changelog value. Generally,
it wouldn't be set, so |today| would have the normal semantics.
Cheers,
-Barry
pgpwAuQgCoHHk.pgp
Description: OpenPGP digital signature
Re: Getting ready for Python 3.5
Dnia 2015-06-23, wto o godzinie 11:38 -0400, Barry Warsaw pisze: > [Apologies for the cross-posting! -BAW] > > For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the > default > Python 3 version. It's currently undecided whether we will keep > Python 3.4 as > a supported version, but a lot of that depends on how easily an > archive port > to Python 3.5 goes. Ideally, we'd be able to make the switch to 3.5 > now ahead > of the planned 16.04 LTS release. > Sorry for maybe stupid question - but do I need to do anything if PyOpenCL is on the list with green checkmark? At the same time - are there plans to upload python3-defaults with enabled support for Python 3.5? I assume that I should still wait for numpy for Python3.5 to be able to properly test PyOpenCL/PyCUDA, but at the same time I'd like to test building them. Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Boto 3 and Debian
Hello. Sorry for cross-posting, but topic touches two mailing lists. There's new version of Boto, library to access AWS cloud services: https://aws.amazon.com/blogs/aws/now-available-aws-sdk-for-python-3 -boto3/ It's API-incompatible with current Boto (2.38). But both boto and boto3 can be installed at the same time. It looks like new Boto uses botocore (already in Debian, although in older version - 0.81). Are there any plans for boto3? And - how can I help? Best regards. -- Tomasz Rybak GPG/PGP key ID: 2AD5 9860 Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860 http://member.acm.org/~tomaszrybak signature.asc Description: This is a digitally signed message part
Re: Getting ready for Python 3.5
On Jun 29, 2015, at 11:43 PM, Tomasz Rybak wrote: >Sorry for maybe stupid question - but do I need to do anything >if PyOpenCL is on the list with green checkmark? Generally, no, but if you can find any dependents of the package that are FTBFS, then helping chase down the chain of problems would help. >At the same time - are there plans to upload python3-defaults with enabled >support for Python 3.5? Yes, but atm, there's no eta. Cheers, -Barry pgpII_515cTG0.pgp Description: OpenPGP digital signature
Re: Getting ready for Python 3.5
On 06/30/2015 12:04 AM, Barry Warsaw wrote: >> At the same time - are there plans to upload python3-defaults with enabled >> support for Python 3.5? > > Yes, but atm, there's no eta. wrong. it's in experimental. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5591c213.7040...@debian.org
Re: Sphinx 1.3 in Debian experimental
On Tue, Jun 30, 2015 at 4:14 AM, Barry Warsaw wrote:
> Maybe upstream would accept a patch similar to what I've done before. It
> could map |today| to the value of an environment variable, if it's set.
> E.g. something like SPHINX_TODAY. Then pybuild, dh_python{2,3}, or some other
> infrastructure piece could set that to the parsed changelog value. Generally,
> it wouldn't be set, so |today| would have the normal semantics.
|today| sounds like a misfeature, more interesting would be |version|
or |source_date|.
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAKTje6Hf3+bK32PcF+mrNZ=0v9wcq+4z7yup-8zp27acpar...@mail.gmail.com
