Re: mkdocs locale error building djangorestframework
On Tue, 2016-01-26 at 11:29 +1100, Brian May wrote: [...] > The problem is that when building djangorestframework, I need to have a > utf8 locale available. C.UTF-8 is fine. However, I don't think there is > any guarantee (??) that a utf8 locale will be available when building > packages. This I believe is the root cause of #812672. > > So should I somehow be trying to get the UTF-8 locale (is this possible > from debian/rules?), or should I submit another bug report against > python3-click saying that it really should work in ASCII environments? C.UTF-8 is built into glibc so I believe you can assume it's present in all Debian installations (from wheezy onward). (The linux source package depends on this already for reproducible docs.) Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: mkdocs locale error building djangorestframework
Ben Hutchings writes: > C.UTF-8 is built into glibc so I believe you can assume it's present in > all Debian installations (from wheezy onward). Ok, this is getting more and more complicated. The only reason I can see for the FTBFS in #812672 is because the C.UTF-8 locale doesn't exist. It shouldn't even be reaching that line of code otherwise. Maybe something to do with building with pbuilder as opposed to sbuild? -- Brian May
Re: mkdocs locale error building djangorestframework
On Tue, 2016-01-26 at 11:49 +1100, Brian May wrote: > Ben Hutchings writes: > > > C.UTF-8 is built into glibc so I believe you can assume it's present in > > all Debian installations (from wheezy onward). > > Ok, this is getting more and more complicated. The only reason I can see > for the FTBFS in #812672 is because the C.UTF-8 locale doesn't exist. It > shouldn't even be reaching that line of code otherwise. > > Maybe something to do with building with pbuilder as opposed to sbuild? That's not the problem at all. Read the error message again. Read the source line it points to. Now look at where rv comes from: >>> import subprocess >>> rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE, ... stderr=subprocess.PIPE).communicate()[0] >>> type(rv) This is clearly a bug in python3-click. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: mkdocs locale error building djangorestframework
Ben Hutchings writes: > That's not the problem at all. Read the error message again. Read the > source line it points to. Now look at where rv comes from: Yes, that is how it would appear. However, all this code does is try to work out the appropriate fatal error message that should get displayed. i.e. we should never have executed this code in the first place. (I did file a bug on the python3 issue however) -- Brian May
Re: mkdocs locale error building djangorestframework
On Tue, 2016-01-26 at 12:16 +1100, Brian May wrote: > Ben Hutchings writes: > > > That's not the problem at all. Read the error message again. Read the > > source line it points to. Now look at where rv comes from: > > Yes, that is how it would appear. > > However, all this code does is try to work out the appropriate fatal > error message that should get displayed. > > i.e. we should never have executed this code in the first place. > > (I did file a bug on the python3 issue however) Oh, well that's probably because you only set LANG and it's being overridden by LC_ALL. Use a bigger hammer: set LC_ALL yourself. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: mkdocs locale error building djangorestframework
Ben Hutchings writes: > Oh, well that's probably because you only set LANG and it's being > overridden by LC_ALL. Use a bigger hammer: set LC_ALL yourself. Yes, somebody mentioned this on the BTS also. I very much suspect this will be the solution. Thanks -- Brian May
Re: mkdocs locale error building djangorestframework
On Tue, Jan 26, 2016 at 1:23:19 +, Ben Hutchings wrote: > On Tue, 2016-01-26 at 12:16 +1100, Brian May wrote: > > Ben Hutchings writes: > > > > > That's not the problem at all. Read the error message again. Read the > > > source line it points to. Now look at where rv comes from: > > > > Yes, that is how it would appear. > > > > However, all this code does is try to work out the appropriate fatal > > error message that should get displayed. > > > > i.e. we should never have executed this code in the first place. > > > > (I did file a bug on the python3 issue however) > > Oh, well that's probably because you only set LANG and it's being > overridden by LC_ALL. Use a bigger hammer: set LC_ALL yourself. > For the wider record: yes, pbuilder sets LC_ALL to C, which has been/is being discussed in #376404 and #725788. It's just a problem surfacing with python3 and will affect a number of packages I'm afraid. Best, Michael signature.asc Description: PGP signature
Re: mkdocs locale error building djangorestframework
On Jan 26, 2016, at 01:12 AM, Ben Hutchings wrote: >That's not the problem at all. Read the error message again. Read the >source line it points to. Now look at where rv comes from: > import subprocess rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE, >... stderr=subprocess.PIPE).communicate()[0] type(rv) > For Python 3, try adding `universal_newlines=True` to any subprocess call. You'll get back a str. Cheers, -Barry pgpDd84p51hjY.pgp Description: OpenPGP digital signature
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > Scott Kitterman writes: > > > At this point I think internal consistency is probably more > > important, so if someone wants to go through and make all the > > python's that should be python2, etc then please send in a patch. > > I'll take that on. I'm planning to provide changes in two bundles: * Go through the whole document and tidy it up for consistency, source style, markup, and language style. This should not change the meaning of anything, but will change the wording of numerous passages. My proposal for that is attached here as a Bazaar change bundle. * Address all the language around Python 2 versus Python 3 versus Python general, and re-order or re-word to focus *primarily* on Python 3, with Python 2 treated as the still-supported legacy system. Once these non-semantic changes are accepted I will begin work on the second stage of semantic changes. I'm maintaining a Bazaar branch for this, feel free to get it:: $ mkdir python.benfinney/ && cd python.benfinney/ $ bzr branch --bind http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/ Currently the log of changes since the ‘pkg-python’ repository (as included in the attached change bundle) looks like:: $ cd devel/ $ bzr log --log-format line --revision ancestor:.. 424: Ben Finney 2016-01-26 Clarify what text is literal names. 423: Ben Finney 2016-01-26 Update copyright notice. 422: Ben Finney 2016-01-26 Refine markup for a compact list. 421: Ben Finney 2016-01-26 Clarify what names are filesystem paths. 420: Ben Finney 2016-01-26 Clarify what names are Debian packages. 419: Ben Finney 2016-01-26 Specify GPLv2 documents explicitly. 418: Ben Finney 2016-01-26 Update external URLs to be current, and use HTTPS. 417: Ben Finney 2016-01-25 Use consistent terminology for “distribution”, “version”, “release”. 416: Ben Finney 2016-01-25 Avoid literal ‘<’ and ‘>’, use SGML character entities. 415: Ben Finney 2016-01-25 Distinguish “Python” the system versus “python” the command. 414: Ben Finney 2016-01-25 Add myself to the document's authors. 413: Ben Finney 2016-01-25 Correct whitespace to conform to Policy style. 412: Ben Finney 2016-01-25 Add editor hints to match Debian Policy text style. 411: Scott Kitterman 2016-01-24 Python policy updates (draft) for Stretch DO NOT UPLOAD YET:wq # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: ben+deb...@benfinney.id.au-20160126051103-\ # 3zbuoy0u0vp14w5d # target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\ # defaults-debian/ # testament_sha1: 765dacf10bafece44db129db818e74a4d0814c0e # timestamp: 2016-01-26 16:43:48 +1100 # source_branch: http://vcs.whitetree.org/bzr/public/debian/python\ # /python-defaults-debian/devel/ # base_revision_id: sc...@kitterman.com-20160124060119-\ # e07prikr3oa8bkbn # # Begin patch === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml revid:sc...@kitterman.com-20160124060119-e07prikr3oa8bkbn +++ debian/python-policy.sgml revid:ben+deb...@benfinney.id.au-20160126051103-3zbuoy0u0vp14w5d @@ -17,24 +17,28 @@ fli...@debian.org -Josselin Mouette + Josselin Mouette j...@debian.org -Joe Wreschnig + Joe Wreschnig pi...@debian.org -Loïc Minier + Loïc Minier l...@debian.org -Scott Kitterman + Scott Kitterman sc...@kitterman.com -Barry Warsaw -ba...@debian.org + Barry Warsaw + ba...@debian.org + + + Ben Finney + ben+deb...@benfinney.id.au version 0.10.1.0 @@ -46,7 +50,7 @@ - Copyright © 1999—2014 Software in the Public Interest + Copyright © 1999–2016 Software in the Public Interest This manual is free software; you can redistribute it and/or @@ -61,11 +65,11 @@ the GNU General Public License for more details. - A copy of the GNU General Public License is available as - /usr/share/common-licences/GPL in the Debian GNU/Linux - distribution or on the World Wide Web at - http://www.gnu.org/copyleft/gpl.html"; - name="The GNU General Public License">. + A copy of the GNU General Public License version 2 is available as + /usr/share/common-licences/GPL-2 in the Debian + GNU/Linux system, or on the World Wide Web at + https://www.gnu.org/licenses/old-licenses/gpl-2.0.html"; + name="GNU General Public License, version 2">. You can also obtain it by writing to the @@ -83,12 +87,12 @@ Debian currently supports two Python stacks, one for Python 2 and one for Python 3. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some - time. - http://legacy.python.org/dev/peps/pep-0404/"; + time. + https://www.python.org/dev/peps/pep-0404/"; name="PEP 404"> states that no more major Python 2 releases - are planned,
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > I'm planning to provide changes in two bundles: > > * Go through the whole document and tidy it up for consistency, source > style, markup, and language style. This should not change the meaning > of anything, but will change the wording of numerous passages. > > My proposal for that is attached here as a Bazaar change bundle. > > * Address all the language around Python 2 versus Python 3 versus Python > general, and re-order or re-word to focus *primarily* on Python 3, > with Python 2 treated as the still-supported legacy system. > > Once these non-semantic changes are accepted I will begin work on the > second stage of semantic changes. That last sentence isn't very clear. What I intended to imply is: The first stage is done and all its changes are in the branch, the second stage I haven't yet started. The set of revision in the “r411–r424” patch bundle is all intended to be non-semantic changes, and once they're accepted I'll begin on the second, semantic-changing, stage of work. -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney
