Bug#812600: ITP: designate-dashboard -- OpenStack DNS as a Service - dashboard plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: designate-dashboard Version : 2.0.0~b2 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/designate-dashboard * License : Apache-2.0 Programming Lang: Python Description : OpenStack DNS as a Service - dashboard plugin Designate provides DNSaaS services for OpenStack. It provides a multi-tenant REST API for domain & record management. It is Integrated with Keystone for authentication, and provides a framework in place to integrate with Nova and Neutron notifications (for auto-generated records). Designate supports PowerDNS and Bind9 out of the box. . This package contains the OpenStack dashboard plugin.
Better Lintian checks
Hi, Newer unstable Lintian version check now package testsuite for licence problems/missing source For instance icedove and iceweasel are now hit by good not evil problem. I expect more problems detected in the next few days Bastien -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Bug#812673: ITP: mopidy-internetarchive -- Mopidy extension for playing music from the Internet Archive
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: mopidy-internetarchive Version : 2.0.0 Upstream Author : Thomas Kemmer * URL : https://github.com/tkem/mopidy-internetarchive * License : Apache-2.0 Programming Lang: Python Description : Mopidy extension for playing music from the Internet Archive Mopidy is a music server which can play music from multiple sources, like your local hard drive, radio streams, and from Spotify and SoundCloud. This package provides a Mopidy extension for playing music from the Internet Archive. The package will be maintained within the pkg-mopidy team on Alioth. signature.asc Description: Digital signature
Bug#812688: ITP: ivy-debian-helper -- Helper tools for building Debian packages with Ivy
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: ivy-debian-helper Version : 1.0 Upstream Author : Emmanuel Bourg * URL : http://anonscm.debian.org/cgit/pkg-java/ivy-debian-helper.git * License : Apache-2.0 Programming Lang: Java Description : Helper tools for building Debian packages with Ivy ivy-debian-helper contains helper tools to ease the packaging of Ivy based projects in Debian. It consists in: * an Ivy plugin resolving the dependencies against the system Maven repository (/usr/share/maven-repo). The resolver uses the same Maven rule files that maven-debian-helper and maven-repo-helper employ (debian/maven.rules, debian/maven.ignoreRules). * a debhelper class initializing the plugin and running Ant+Ivy in offline mode.
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
On Tue, Jan 26, 2016 at 11:29:07AM +1100, Brian May wrote: > python3-click has checks to ensure it is called with a non-ASCII > locale. Or if it is an ASCII locale, it raises a fatal error. Or at > least it tries to raise a fatal error. [...] > 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?) C.UTF-8 is always available on Debian since a long time ago, precisely to be a guaranteed UTF-8 locale. It's included in the libc-bin package which is Essential:yes. My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set to an ancient locale. These variables override LANG, the order is LC_ALL>LC_CTYPE>LANG. > should I submit another bug report against > python3-click saying that it really should work in ASCII environments? My personal preference would be to drop support for non-UTF8 locales as soon as possible. They're a heap of work; that effort could be better spent fixing remaining problems in UTF-8 locales. -- A tit a day keeps the vet away.
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
Adam Borowski writes: > My guess as to the cause of #812672 is that you have LC_CTYPE or LC_ALL set > to an ancient locale. These variables override LANG, the order is > LC_ALL>LC_CTYPE>LANG. Interesting thought. Unfortunately, I can't tell from the supplied build logs what these are set to. I probably should change the line from: LANG=C.UTF-8 mkdocs build && mv site docs.debian/html To something like: LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html Just in case. -- 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 pgpnuq4igREKj.pgp Description: OpenPGP digital signature
Re: Better Lintian checks
On 25-01-16 19:47, Bastien Roucaries wrote: > I expect more problems detected in the next few days I guess the autorejects for Multi-Arch: no are among those problems. The use of Multi-Arch: no was suggested by https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html The reject message refers to #768353 which was fixed in November 2014, but the fix is most likely not available in stable yet, and hence still an issue on the Debian infrastructure? If "Multi-Arch: no support in Debian is broken" is still true, the suggested fix for old-style-config-script-multiarch-path is not an actual solution. Should the autoreject be removed, or should lintian suggest a different fix? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: mkdocs locale error building djangorestframework
❦ 26 janvier 2016 11:57 +1100, Brian May : > I probably should change the line from: > > LANG=C.UTF-8 mkdocs build && mv site docs.debian/html > > To something like: > > LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html This may not apply to your case, but there is a localehelper package for this kind of situations. -- Make input easy to prepare and output self-explanatory. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
