On 06/11/2015 10:08 AM, Duncan Thomas wrote:
On 11 June 2015 at 10:26, Thomas Goirand z...@debian.org
mailto:z...@debian.org wrote:
Hi,
The current maintainer of suds in Debian sent bug reports against all
packages depending on it. We would like to get rid of suds completely
://bugs.launchpad.net/nova/+bug/1465016
https://bugs.launchpad.net/cinder/+bug/1465017
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
On 06/15/2015 10:43 PM, Paul Belanger wrote:
On 06/15/2015 03:03 PM, Allison Randal wrote:
On 06/15/2015 11:48 AM, Thomas Goirand wrote:
On 06/15/2015 04:55 PM, James Page wrote:
The problem of managing delta and allowing a good level of
distribution independence is still going to continue
these packages, and as we have strong package ownership in
Debian, I have to get in touch with the maintainer first... and that can
take some time!).
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List
On 06/15/2015 04:55 PM, James Page wrote:
Hi All
On 27/05/15 09:14, Thomas Goirand wrote:
tl;dr: - We'd like to push distribution packaging of OpenStack on
upstream gerrit with reviews. - The intention is to better share
the workload, and improve the overall QA for packaging *and*
upstream
times
on the blueprint, but I basically got ignored.
If we want this blueprint to get through, please take into account
remarks that reviewers are making.
Cheers,
Thomas Goirand (zigo)
[1]
https://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
[2]
https
://bugs.debian.org/788088
Affected projects are: cinder, nova, trove, ironic, and finally oslo.vmware.
So, are we moving to suds-jurko? Or anything else?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage
On 06/15/2015 05:19 PM, Ian Cordasco wrote:
On 6/15/15, 09:24, Thomas Goirand z...@debian.org wrote:
On 06/08/2015 01:55 PM, Kuvaja, Erno wrote:
One thing I like about plan D
is that it would give also indicator how much the stable branch has
moved in
each individual project.
The only
On 06/14/2015 03:46 PM, Thomas Goirand wrote:
On 06/11/2015 11:31 PM, Nikhil Manchanda wrote:
Hi Thomas:
I just checked and I don't see suds as a requirement for trove.
I don't think it should be a requirement for the trove debian package,
either.
Thanks,
Nikhil
Hi,
I fixed
few years.
Last word: thanks to everyone on the infra team (and others) which were
supportive of the project. All of this is very exciting, and it's really
great that this is finally happening.
Cheers,
Thomas Goirand (zigo)
[1]
https://qa.debian.org/developer.php?login=openstack-de
arch, the daily
downloads are about 6 GB, but with amd64, this should drop
significantly). These were stats that I read a year or 2 ago, though I
don't think it has changed much over time. Thoughts about this anyone?
Thomas Goirand (zigo
sphinx theme from 'default' to 'classic'? That's really
not worth the amount of pain everyone will have. The person who did this
should be taking care of unbreaking all the things he broke. :(
Cheers,
Thomas Goirand (zigo
,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 05/29/2015 11:03 PM, Jeremy Stanley wrote:
On 2015-05-28 23:19:36 +0200 (+0200), Thomas Goirand wrote:
[...]
By the way, I was thinking about the sbuild package caching system, and
thought: how about network mounting /var/cache/pbuilder/aptcache using
something like Manila (or any other
see,
I've used /stackforge/deb-* as prefix. This will be used by both Debian
and Ubuntu (we already both use it in our packaging).
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions
Derek,
Thanks for what you wrote.
On 05/27/2015 11:26 PM, Derek Higgins wrote:
4. For deb packages you can create new repositories along side the
rdorpm-* repositories
My intention is to use deb-* as prefix, if Canonical team agrees.
5. Add deb support to delorean, I know of at least one
On 06/02/2015 02:39 PM, Jeremy Stanley wrote:
On 2015-06-02 09:02:42 +0200 (+0200), Thomas Goirand wrote:
[...]
That will be the little bit more tricky part. Some libraries are very
small, and probably caching will not be useful (too much work when
building the VM image). However, for big
On 07/01/2015 04:08 AM, Tony Breeds wrote:
On Wed, Jul 01, 2015 at 03:55:53AM +0200, Thomas Goirand wrote:
Please don't do this. This is the kind of job to be done by package
maintainers in distribution, because mostly, Python maintainers wouldn't
know how to do things correctly. Here we've
important than the old Py 2.6.
Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
happen with Neutron
packages), and it's a mess to un-cruft.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
On 07/02/2015 05:51 AM, Robert Collins wrote:
On 2 July 2015 at 13:26, Thomas Goirand z...@debian.org wrote:
On 07/02/2015 02:07 AM, Tony Breeds wrote:
On Wed, Jul 01, 2015 at 11:07:30PM +, Perry, Sean wrote:
BTW, see dh_bash-completion from the debhelper package. When in doubt
about
-completion/completions
there's even a lintian warning about it.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
On 07/02/2015 12:26 AM, Tony Breeds wrote:
On Wed, Jul 01, 2015 at 01:33:03PM +0200, Thomas Goirand wrote:
The file has nothing to do in /usr/share/doc either. By per the debian
policy manual: we shouldn't rely on /usr/share/doc, as it can be removed
entirely by the users. /usr/share/python
the system packages)
Use the source, luke! Or write yourself a small shell script...
2) Help the system/distribution packagers or at the very least not make thier
life more difficult.
If you attempt to address this, you're making my life miserable. Please
don't do it, thanks.
Cheers,
Thomas
On 06/29/2015 12:01 PM, Victor Stinner wrote:
Hi,
Le 29/06/2015 11:03, Thomas Goirand a écrit :
cliff-tablib is used for the unit tests of things like
python-neutronclient. The annoying bit is that cliff-tablib depends on
tablib, which itself is a huge mess. It has loads of 3rd party
-openstackclient, recently, cliff-tablib was
added. Let's do the reverse, and remove cliff-tablib whenever possible.
If we really want to keep using cliff-tablib, then someone has to do the
work to port tablib to Python3 (good luck with that...).
Your thoughts anyone?
Cheers,
Thomas Goirand (zigo
also looking forward switching to Yaql 1.0 on the packaging
level, because 0.2.6 has lost support for Py3 (I added some Py3 patches
in Debian for 0.2.4, but 0.2.6 completely broke that...).
Cheers,
Thomas Goirand (zigo
On 07/24/2015 11:07 AM, Thierry Carrez wrote:
Igor Yozhikov wrote:
Hello again to everyone, resending this letter due to typo in the topic
of the previous letter, apologize for this.
*
Introductory words:*
I want to present renewed proposal for packaging of OpenStack
components for deb
On 07/27/2015 11:42 PM, William M Edmonds wrote:
python-swiftclient is only needed by operators that are using the swift
backend, so it really doesn't belong in requirements.txt. Listing it in
requirements forces all operators to install it, even if they're not
going to use the swift backend.
On 07/20/2015 08:26 PM, Brant Knudson wrote:
On Fri, Jul 17, 2015 at 7:32 AM, Victor Stinner vstin...@redhat.com
mailto:vstin...@redhat.com wrote:
Hi,
...
(3) keystonemiddleware: blocked by python-memcached, I sent a pull
request 3 months ago and I'm still waiting...
On 07/14/2015 03:55 AM, Jeremy Stanley wrote:
On 2015-07-14 00:33:52 +0200 (+0200), Thomas Goirand wrote:
[...]
I believe I asked you about 10 times to keep these branches alive, so
that distributions could work together on a longer support, even without
a CI behind it.
And the project
On 07/14/2015 10:29 AM, Ihar Hrachyshka wrote:
On 07/14/2015 12:33 AM, Thomas Goirand wrote:
I missed this announce...
On 07/02/2015 05:32 AM, Jeremy Stanley wrote:
Per the Icehouse EOL discussion[1] last month, now that the
final 2014.1.5 release[2] is behind us I have followed our usual
On 07/15/2015 12:05 PM, Thierry Carrez wrote:
The cost of keeping stable branches around without CI is more a
branding cost than a technical cost, I think.
Which is why I suggested to rename the branches, if it poses a problem.
For example eol/icehouse would have been fine.
An OpenStack
On 07/15/2015 12:37 PM, Ihar Hrachyshka wrote:
On 07/14/2015 09:14 PM, Thomas Goirand wrote:
On 07/14/2015 10:29 AM, Ihar Hrachyshka wrote:
On 07/14/2015 12:33 AM, Thomas Goirand wrote:
I missed this announce...
On 07/02/2015 05:32 AM, Jeremy Stanley wrote:
Per the Icehouse EOL discussion[1
of OpenStack.
Let's hope we find the time to get this done.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
Hi,
I've seen that the latest version of taskflow needs fasteners, which
handles lock stuff. Why can't this goes into oslo.concurrency?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage
, used only for testing)
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
the later means some significant work, I don't
understand why you have deleted the Icehouse branches.
Effectively, under these conditions, I am giving up doing any kind of
coordination between distros for security patches of Icehouse. :(
Thomas Goirand (zigo
On 08/25/2015 03:42 PM, Thomas Goirand wrote:
Hi,
[...]
Anyway, the result is that mock 1.3 broke 9 packages at least in Kilo,
currently in Sid [1]. Maybe, as packages gets rebuilt, I'll get more bug
reports. This really, is a depressing situation.
[...]
Some ppl on IRC explained to me what
n upstream code on some weirdo
dependencies that I don't fully understand.
So, would anyone be able to invest a bit of time, and help me fix the
problems with repoze.what / repoze.who in Debian? If you can help,
please ping me on IRC.
Cheers,
Thoma
not be done because it's windows, then remove
the windows part and host it in another (non-free) git repository.
Yes, it will be more painful for you to work on it. Though we have no
choice: we're doing free software.
Cheers,
Thomas Goirand (zigo)
___
I can
hook my script.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
On 10/15/2015 12:18 AM, Robert Collins wrote:
> On 15 October 2015 at 11:11, Thomas Goirand <z...@debian.org> wrote:
>>
>> One major pain point is unfortunately something ridiculously easy to
>> fix, but which nobody seems to care about: the long & short descriptio
On 10/13/2015 09:41 AM, Cory Benfield wrote:
>
>> On 13 Oct 2015, at 07:42, Thomas Goirand <z...@debian.org> wrote:
>> In this particular case (ie: a difficult upstream which makes it
>> impossible to have the same result with pip and system packages)
>
>
On 10/13/2015 06:04 PM, Joshua Harlow wrote:
> Thomas Goirand wrote:
>> On 10/13/2015 12:44 AM, Joshua Harlow wrote:
>>> Anvil gets somewhat far on this, although its not supporting DEBs it
>>> does build its best attempt at RPMs building them automatically and
>&g
too - which is that (at least at one point
> in the past) upstream expressed frustration with the idea of distro
> packages of Cassandra because it led to people coming to them with
> complaints about the software which had been fixed in newer versions but
> which, because of distro su
On 10/14/2015 07:18 AM, Akihiro Motoki wrote:
> 2015-10-14 0:14 GMT+09:00 Doug Hellmann <d...@doughellmann.com>:
>> Excerpts from Thomas Goirand's message of 2015-10-13 12:38:00 +0200:
>>> On 10/12/2015 11:09 PM, Steve Baker wrote:
>>>> On 13/10/15 02:05, T
cies to remove cliff-tablib. Someone just needs to
> follow through on that with patches to the requirements files for the
> clients.
>
>
> For OpenStackClient: https://review.openstack.org/234406
>
> dt
Cool!
Could I also remove it from the Liberty version of
On 10/13/2015 05:14 PM, Doug Hellmann wrote:
> Excerpts from Thomas Goirand's message of 2015-10-13 12:38:00 +0200:
>> On 10/12/2015 11:09 PM, Steve Baker wrote:
>>> On 13/10/15 02:05, Thomas Goirand wrote:
>>>>
>>>> BTW, the same applies for tab
On 10/15/2015 03:59 PM, Monty Taylor wrote:
> On 10/15/2015 02:53 AM, Thomas Goirand wrote:
>> Well, having the changlog (and other stuff) of packages merged into the
>> long description is not helpful, not for Debian, nor for upstream Python
>> packages.
>
> I ac
02 Liberty (and related) packages to
move them from Debian Experimental to Sid, and after that, I'll have a 5
days break, then the Tokyo summit... But after that, removing tablib
from the equation will allow me to bring even more Python 3 support in
packages, which is grea
On 10/15/2015 12:08 PM, Cory Benfield wrote:
>> On 14 Oct 2015, at 23:23, Thomas Goirand <z...@debian.org> wrote:
>> Though you could have avoid all of this pain if you were not bundling.
>> Isn't all of this make you re-think your vendorizing policy? Or still
>> n
.e. in the background) ?
>
>
> Cheers,
> Alan
What you describe above looks like a defect in the implementation. Of
course, waiting for more than 90s should be considered as failed, and I
wouldn't want in any case to have this timeout increased. Failed
attempts to connect
On 10/15/2015 11:20 AM, Dmitry Tantsur wrote:
> On 10/15/2015 12:18 AM, Robert Collins wrote:
>> On 15 October 2015 at 11:11, Thomas Goirand <z...@debian.org> wrote:
>>>
>>> One major pain point is unfortunately something ridiculously easy to
>>> fix, but
On 12/15/2014 04:21 PM, Ihar Hrachyshka wrote:
> On 14/12/14 09:45, Thomas Goirand wrote:
>> Hi,
>
>> As I am slowing fixing all systemd issues for the daemons of
>> OpenStack in Debian (and hopefully, have this ready before the
>> freeze of Jessie), I was wonderin
back-end cannot be Cassandra the way it is now.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc
ian or Ubuntu. At least
*I* wouldn't.
That being said, maybe the issue that Clint quoted is fixable. Probably
the issue is that nobody really cares... (yet?)
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing L
ts Python dependencies (and
> hopefully they can update that in stable releases).
The maintainer for both urllib3 and requests is a single person, so I'm
quite sure he is aware of the issue, and make sure that both packages
are compatible. Otherwise, opening bugs in Debian [1] to have him
env with pip install works perfectly. There's only
one issue with this: Python 3 and namespace. This is by the way one of
the reason we removed the namespace from the Oslo libs, it didn't work
well for Python 3 and namespace to run tests for
ncy list, if someone cares about
re-writing cliff-tablib, which IMO wouldn't be that much work. Doug, how
many beers shall I offer you for that work? :)
Just my 2 cents hopping to provide some contrib in this discussion,
Cheers,
Thomas Goirand (z
opment perspective, it doesn't seem to fit real-world usage. I
> don't think it would make operators very happy.
This thread has nothing to do with operators. Operators typically
install from distro packages only (unless they do like Helion does,
which is pretty rare...) and wouldn't be affec
On 10/07/2015 02:06 AM, Monty Taylor wrote:
> The Big Tent has absolutely no change in opinion about eliminating
> diversity of tools. OpenStack has ALWAYS striven to reduce diversity of
> tools. Big Tent applies OpenStack to more things that request to be part
> of OpenStack.
>
> Nothing has
are really dependent of the distro. For example, the libvirt unix
group is libvirt in Debian, but libvirtd in Ubuntu. This difference has
to stay depending on the OS type, which we absolutely do not want to
overwrite. So we do want variables for the *OpenStack package type*
which is running on top
On 10/07/2015 03:57 PM, Hayes, Graham wrote:
> On 07/10/15 14:42, Ryan Brown wrote:
>> On 10/06/2015 05:15 PM, Thomas Goirand wrote:
>>> P.S: It wasn't the point of this message, but do we have a fix for
>>> designateclient? It'd be nice to have this
On 10/07/2015 03:39 PM, Ryan Brown wrote:
> Sharing a flat namespace is a recipe for pain with a growing number of
> projects. Devs and users are unlikely to use every project, they
> probably won't notice conflicts naturally except in cases like horizon.
Well, users would typically install
On 10/12/2015 03:58 PM, Jeremy Stanley wrote:
> On 2015-10-12 15:40:48 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> Has the infra team ever thought about doing that for (at least) all of
>> the 3rd party libs we use? I'd love to work closer with the infra team
>> to p
Python modules, if it was PHP pear packages, it
could be fully automated. So probably there's some PEP that we could
start to ease this. If only everyone was using testr, pbr, defining
copyright correctly and providing a parseable long and short
description, it wouldn't be such an issue.
to using oslo.service, and is _sd_notify always called when a
package declares a dependency on oslo.service? Could someone confirm a
list of projects for which I could enable Type=notify in all daemons?
Cheers,
Thomas Goirand (zigo
On 10/12/2015 11:09 PM, Steve Baker wrote:
> On 13/10/15 02:05, Thomas Goirand wrote:
>>
>> BTW, the same applies for tablib which is in a even more horrible state
>> that makes it impossible to package with Py3 support. But tablib could
>> be removed from our (build-)
d really nice if we
could have some kind of checks to make sure that conflicts are either 1/
not possible or 2/ handled gracefully.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
P.S: It wasn't the point of this message, but do we have a fix for
designateclient? It'd be nice
g a 3rd
party new dependency in. I hope we can talk about this in Tokyo. That
being said, indeed, adding py.test isn't so much of a problem, as it is
widely used, already packaged, and maintained upstream. I'd still prefer
if all projects were using the same t
On 08/25/2015 08:59 PM, Matt Riedemann wrote:
On 8/25/2015 10:04 AM, Thomas Goirand wrote:
On 08/25/2015 03:42 PM, Thomas Goirand wrote:
Hi,
[...]
Anyway, the result is that mock 1.3 broke 9 packages at least in Kilo,
currently in Sid [1]. Maybe, as packages gets rebuilt, I'll get more
about it, but I'll try to
be more careful when choosing my words. Hopefully, no more breakage will
be needed.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
release; you may need the related dependencies updated as well though
Yes, which maybe is the problem (as per above). I prefer to not attempt
it right now, as it would be a lot of work.
Cheers,
Thomas Goirand (zigo
l-design-icons
the question is then, how has this font been made? Was it done "by hand"
by an artist? Or was there some kind of scripting involved? If it is the
later, then I'd like to build the font out of the original sources if
possible. If I can't find how it was done, then I'll probab
package quality insurance, so I would
definitively love running these tests. Please help me doing so! :)
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
some installations.
So I wonder if using bootswatch, which includes such a problem, is
really a good idea. Are these fonts import completely mandatory? Or can
I patch them out? Will the result be ugly if I patch it out?
Your thoughts?
Cheers,
Thomas Goirand
is with testtools (ie: #796542). I'd
appreciate having help on that one.
I hope the message is heard and that it wont happen again.
Cheers,
Thomas Goirand (zigo)
[1]
https://bugs.debian.org/795128 [src:python-barbicanclient]
python-barbicanclient: FTBFS: test_delete_checks_status_code
On 09/16/2015 11:33 AM, Thierry Carrez wrote:
> Hi everyone,
>
> I have been handling release management for OpenStack since the
> beginning of this story, well before Release Management was a program or
> a project team needing a proper elected PTL. Until recently it was
> largely a one-man job.
On 09/25/2015 05:00 PM, Ryan Brown wrote:
> I believe the 72 limit is derived from 80-8 (terminal width - tab width)
If I'm not mistaking, 72 is because of the email format limitation.
Thomas
__
OpenStack Development
enStack Gerrit with gating will happen at least for a few
packages during the Mitaka cycle, and that Debian will become the common
community platform for OpenStack as I always wanted it to be.
Happy OpenStack Liberty hacking,
Thomas
for this cycle: I do need holidays...
So let me do it once more: thanks everyone! :)
Looking forward to meet so many friends in Tokyo,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
On 09/30/2015 01:58 PM, Thomas Goirand wrote:
> 3/ Horizon dependencies still in NEW queue
> ==
>
> It is also worth noting that Horizon hasn't been fully FTP master
> approved, and that some packages are still remaining in the NEW queu
between the upstream Debian or CentOS packages. What is the
best way to add this variable values?
Could you Puppet experts explain to me and my Mirantis colleagues again?
Sorry that I didn't take notes about it and couldn't explain,
Cheers,
Thomas Goirand (zigo)
P.S: Where may I find the bes
On 10/01/2015 09:39 PM, Thomas Goirand wrote:
> On 09/30/2015 01:58 PM, Thomas Goirand wrote:
>> 3/ Horizon dependencies still in NEW queue
>> ==
>>
>> It is also worth noting that Horizon hasn't been fully FTP master
>>
q -d , -H 'SELECT ID FROM - WHERE `Service Name`="cinder"'
This is so much better than any awk hacks to get IDs... :)
I just wanted to share, hoping it could be useful to someone.
Cheers,
Thomas Goirand (zigo)
___
to do this for each and every OpenStack component, and I suppose
everyone understands how frustrating it is...
I also wonder where this /usr/etc is coming from. If it was
/usr/local/etc, I could somehow get it. But here... ?!?
Cheers,
Thomas Goirand (zigo
ig-generator flat neutron.conf as a release goal
for Mitaka as well? The current configuration layout makes it difficult
for distributions to catch-up with working by default config.
Cheers,
Thomas Goirand (zigo)
__
O
On 12/08/2015 03:48 AM, Anne Gentle wrote:
>
>
> On Mon, Dec 7, 2015 at 3:18 PM, Cory Benfield <c...@lukasa.co.uk
> <mailto:c...@lukasa.co.uk>> wrote:
>
>
> > On 7 Dec 2015, at 18:37, Thomas Goirand <z...@debian.org
> <mailto:z...@debian.org>
Cory,
Thanks a lot for this patch.
If I understand well, in Debian, I'd have to remove the:
[options]
analytics_tracking_code = UA-17511903-1
from the default theme.conf to make the GA code go away. Right? Would
there be a way so that I could set an
Can't we just use
what's in the system already? As far I as I remember, the awesome font
is very close from the system ones (like DejaVu, for example). Maybe
there could be such a fallback at least?
Cheers,
Thomas Goirand (zigo)
___
istic for openstack.org" than just Google Analytics.
So, could we have a general policy that we stop having such external
resources in our documentations? What's the broader view of the
community on this issue?
Cheers,
Thomas Goirand (zigo)
P.S: Here's the output of lintian when generating
on_2:_Python_2.6_support_dropped.2C_Python_2.7_only
I believe [1] is obsolete already. Please *completely* remove Py2.6
support, including in fuelclient. This otherwise create issues on the
packaging level (like having to patch out modules l
Keystone has broken free, you are then
> free to deploy our generic WSGI app/s using any generic WSGI server in
> any process / threading architecture that suits your requirements.
>
> We only ever preferred Apache for two reasons:
>
> 1) There was interest in using apache-based auth pl
On 12/04/2015 03:23 PM, Anne Gentle wrote:
>
>
> On Fri, Dec 4, 2015 at 8:09 AM, Thomas Goirand <z...@debian.org
> <mailto:z...@debian.org>> wrote:
>
> Hi,
>
> I've investigated a bit the openstackdocstheme, and tried to remove some
> of
n in Python? Isn't it
possible to write a decent HTTP server in Python? Why are we forced into
just Eventlet for doing the job? I haven't searched around, but there
must be loads of alternatives, no?
Cheers,
Thomas Goirand (zigo)
On 12/07/2015 06:07 PM, Cory Benfield wrote:
>
>> On 7 Dec 2015, at 16:10, Thomas Goirand <z...@debian.org> wrote:
>>
>> Cory,
>>
>> Thanks a lot for this patch.
>>
>> If I understand well, in Debian, I'd have to remove the:
>>
>>
On 12/07/2015 10:18 PM, Cory Benfield wrote:
>
>> On 7 Dec 2015, at 18:37, Thomas Goirand <z...@debian.org> wrote:
>>
>>
>> The reason why I'd like an env var, is that I could simply modify
>> openstack-pkg-tools (which is included in every debian/rules) t
etely optional, and most of the
helpers are completely disabled by default. So it is *not* in the way of
using any deployment tool like puppet.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (no
hoping to get a thanks for even *testing* unreleased versions of
> my entirely non-Openstack, upstream projects against Openstack itself.
> If I did *less* effort here, and just didn't bother the way 100% of all
> other non-Openstack projects do, then I'd not have been scolded by you.
I
301 - 400 of 662 matches
Mail list logo
