Blocking the acceptance of new projects seems punitive and against the spirit
of the big tent. Classification (tagging) can be done at any point, and is
hardly fixed in stone. You can refine tags as needed.
To put it harshly: it is a failure of both leadership and process to have
stripped out
thing and is better principle.
Also it makes Bandit happy, and it's one less thing to flag in the
future.
** Affects: horizon
Importance: Low
Assignee: Gabriel Hurley (gabriel-hurley)
Status: In Progress
** Changed in: horizon
Status: New = Confirmed
** Changed in: horizon
As the former Horizon PTL, I have a great respect for the importance of the
contributions the distro maintainers/developers make to Horizon and OpenStack
as a whole. From how many bugs the distros manage to find, to their diligence
in vetting the software that we as Horizon developers provide,
Two things of note, having been doing heavy javascript development over the
past couple years:
1) NPM actually resolves conflicts in a dependency tree. Unlike Python, it can
ensure that if different packages declare conflicting versions, each one gets
the version it requested. And conflicting
I have no familiarity with stacktach, but it sounds like it's trampling data on
the sessionid cookie (even if it's also setting a beaker.session.stacktach
cookie).
Your options include running the two at different domains/subdomains (and
specifying the subdomain as the cookie domain; that
SQLite doesn't introduce any additional dependencies, memcached requires
installation of memcached (admittedly it's not hard on most distros, but it
*is* yet another step) and in most cases the installation of another python
module to interface with it.
Memcached might be a good choice for
All in all this is been a long time coming. The cookie-based option was useful
as a batteries-included, simplest-case scenario. Moving to SQLite is a
reasonable second choice since most systems Horizon might be deployed on
support sqlite out of the box.
I would make a couple notes:
1)
Public bug reported:
The mask_password function of openstack.common.log and/or
openstack.common.strutils (depending on OpenStack version) seems to
choke on unicode characters. This actually prevents proper function when
logging level is set to DEBUG.
When submitting a POST request to create a
This is generally the right plan. The hard parts are in getting people to
deploy it correctly and securely, and handling fallback cases for lack of
browser support, etc.
What we really don't want to do is to encourage people to set
Access-Control-Allow-Origin: * type headers or other such
I would also like to add that incubated != integrated. There's no telling how
long a project may stay in incubation or how many changes it may undergo before
it's deemed ready (see David's reasoning around client changes during RC's).
While the Horizon team has always made every effort to work
While you *can* hack things around to make it work, the answer is that
out-of-the-box it’s not supported. In the Horizon Quickstart guide it lists
“Nova (compute, api, scheduler, and network), Glance, and Keystone” as the
minimum required services. All others are optionally supported from
”.
- Gabriel
From: Brent Troge [mailto:brenttroge2...@gmail.com]
Sent: Tuesday, August 19, 2014 12:45 PM
To: Gabriel Hurley
Cc: openstack@lists.openstack.org
Subject: Re: [Openstack] SWIFT AND HORIZON
Right, I saw the minimum requirement list, but figured that was outdated, due
At the point at which the Horizon project first began (during the Cactus, I
believe) the handful of folks working on it wanted a Python web framework that
would get them up and running as fast as possible. That meant lots of built-in,
“batteries-included” features so they didn’t need to
I've implemented Kerberos (via Apache) + Django once before, and yes, taking
this as pseudo-code you're on the right track. Obviously the devil is in the
details and you'll work out the particulars as you go.
The most important bit (obviously) is just making absolutely sure your
REMOTE_USER
[mailto:ayo...@redhat.com]
Sent: Wednesday, June 04, 2014 12:43 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Kerberization of Horizon (kerbhorizon?)
On 06/04/2014 03:10 PM, Gabriel Hurley wrote:
I've implemented Kerberos (via Apache) + Django once before, and yes, taking
Forgive me if I'm misunderstanding, but those all look like repositories that
are strictly tracking upstreams. They're not maintained by the
Horizon/OpenStack developers whatsoever. Is this intentional/necessary?
- Gabriel
-Original Message-
From: Anita Kuno
It's sort of a silly point, but as someone who would likely consume the
split-off package outside of the OpenStack context, please give it a proper
name instead of django_horizon. The module only works in Django, the name
adds both clutter and confusion, and it's against the Django community's
I would imagine the downstream distros won't have the same problems with Ruby
as they did with Node.js from a dependency standpoint, though it still doesn't
jive with the community's all-Python bias.
My real concern, though, is anyone who may have extended the Horizon
stylesheets using the
Yes this is one approach if keystone really wants to extend domains to work
this way, but I think this is more complex than just using nested projects.
Having domains contain domains containing projects is less intuitive than
projects all the way down.
It's worth mentioning that at the
Adding this to glanceclient is probably acceptable since the worst abuse of it
would be to disrupt a user's local machine until they terminated the process,
but adding this to Horizon is a no-go.
Django removed the verify_exists option from URLField in Django 1.5 for very
good reasons. Here's
The reason the architecture is the way it is in Horizon right now is because
historically most projects have sent messages that are either raw tracebacks
(not appropriate for a popup error display at all), extremely
detailed/technical reports containing multiple resource IDs that are not
I've also used the core Horizon bits for dashboards other than the OpenStack
dashboard. I can't speak for any current bugs you may run into, but
by-and-large the ability to create arbitrary dashboards, tables, workflows,
etc. to interact with RESTful APIs works perfectly without the OpenStack
Martinelli; Jamie Lennox; David Stanek; Andy Smith; Gabriel Hurley;
Joe Heck; Devin Carlen
Subject: [keystone] Changes to keystone-core!
Hello everyone!
We've been talking this for a long while, and we finally have a bunch of
changes to make to keystone-core all at once. A few people have moved
From my experience, directly adding incubated projects to the main Horizon
codebase prior to graduation has been fraught with peril. That said, the
closer they can be together prior to the graduation merge, the better.
I like the idea of these types of projects being under the OpenStack
I've run into a use case that doesn't currently seem to have a great solution:
Let's say my users want to use a top-of-stack OpenStack project such as Heat,
Trove, etc. that I don't currently support in my deployment. There's absolutely
no reason these services can't live happily in a VM
+1 on Tatiana Mazur being added to Core.
I'm also okay with cleaning out the Core list. I considered doing it myself
last cycle since none of those folks are involved anymore, but figured I'd
leave them as a posthumous honor. ;-) I think now's a good time to trim it down.
Glad I didn't make
who can devote their full attention and energy to it.
I will still be around and engaged (though not in Hong Kong). I'll catch you
all next time around.
All the best,
- Gabriel Hurley
___
OpenStack-dev mailing list
OpenStack-dev
Karlson
endre.karl...@gmail.commailto:endre.karl...@gmail.com
Hey, I'm just curious. You quitting the PTL position to focus on Nebula efforts
or ?
2013/10/31 Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com
Hi all,
It saddens me to say that for a mix of reasons I have
The answer is sort of. Most projects (including Nova) publish to an RPC
notifications channel (e.g. in rabbitMQ or whichever you use in your
deployment). This is how Ceilometer gets some of its data.
There is common code for connecting to the notification queue in Oslo (the
rpc and notifier
FWIW, Django 1.6 is not officially supported with Horizon yet.
That aside, pickle is generally a security risk (it's equivalent to eval),
hence the move away from it in Django. We'll want to see what we can do about
making things properly serializable with the JSON serializer in Icehouse. It
Board and the TC, coordination within OpenStack, and more, but I won't go into
those now.
Hopefully I've proven myself thus far to be a considered and well-reasoned
member of the TC. It would be my honor to consider doing the good work of
OpenStack.
Thank you,
- Gabriel Hurley
Yes and No. They will appear to be logged in to Horizon, but the Keystone token
will be invalid and thus they will be unable to obtain any data or perform any
actions via the APIs. Since all of Horizon's data comes from APIs, this is a
very limited problem space.
There are reasonably
Hi Kaiwai,
First, the bad news:
1. The Horizon release candidate has already been cut, so for Havana we're only
considering release-blocking bugs at this point (and even those have to meet a
high bar to warrant a new release candidate). The feature freeze deadline was
almost a month ago.
2.
Looks like you answered your own question. The translations that were
provided to Horizon by the translation team were merged just in the last
few hours. If yours weren't included, that's probably why.
** Changed in: horizon
Status: New = Invalid
--
You received this bug notification
: (unassigned) = Gabriel Hurley (gabriel-hurley)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1231887
Title:
Create a volume from image fails
Status in Cinder
*** This bug is a duplicate of bug 1231887 ***
https://bugs.launchpad.net/bugs/1231887
** Changed in: horizon
Milestone: havana-rc1 = None
** This bug has been marked a duplicate of bug 1231887
Create a volume from image fails
--
You received this bug notification because you are a
On a clean environment with current master I cannot reproduce this
error.
** Changed in: horizon
Importance: Medium = Undecided
** Changed in: horizon
Status: Triaged = Invalid
** Changed in: horizon
Milestone: havana-rc1 = None
--
You received this bug notification because you
more.
If you still have any concerns, let me know I will try to be more explicit.
-- Jarda
On 2013/25/09 02:03, Gabriel Hurley wrote:
Really digging a lot of that. Particularly the inter-rack/inter-node
communication stuff around page 36ish or so.
I’m concerned about using the term “Class”. Maybe
I have a question on this:
I logged in to take the user survey, and it still had all of my answers from
the last user survey filled in. If this is intentional, it's very strange
behavior. I don't feel that I should be overwriting my previous answers. That
feels oddly invalidating. It also
3. There is a thought about watching correlation of multiple alarm
histories in one Chart (either Alarm Histories, or the real statistics
the Alarm is defined by). Do you think it will be needed? Any real
life examples you have in mind?
I think the first use case is to debug combined
Really digging a lot of that. Particularly the inter-rack/inter-node
communication stuff around page 36ish or so.
I’m concerned about using the term “Class”. Maybe it’s just me as a developer,
but I couldn’t think of a more generic, less inherently meaningful word there.
I read through it and
I hereby declare my candidacy for the Horizon PTL position.
My current qualifications:
* PTL for the Grizzly and Havana cycles.
* Core developer on Horizon since Essex, and Keystone core since Folsom.
* Primary architect of the existing Horizon framework.
* Core developer for the Django
I'm also strongly against reverting the move to lesscpy. As David said, that
change was highly-requested by the downstream distros and other folks packaging
Horizon in various ways.
Since there's no evidence that lesscpy does not intend to support bootstrap 3
in a reasonable timeframe,
This was not a bug in Horizon trunk.
** Changed in: horizon
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to horizon in Ubuntu.
https://bugs.launchpad.net/bugs/1210253
Title:
With Havana 2 installed,
Closing this out due to inactivity and proper fix suggestions in the
comments.
** Changed in: horizon
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1181150
Title:
This was not a bug in Horizon trunk.
** Changed in: horizon
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1210253
Title:
With Havana 2 installed, Launching horizon
This was not a bug in Horizon trunk.
** Changed in: horizon
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1210253
Title:
With
Closing this out due to inactivity and proper fix suggestions in the
comments.
** Changed in: horizon
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
Closing out since this has been fixed to the best of my knowledge
** Changed in: horizon
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
Correct, the quota management changes that took place to support this
have been an extensive and ongoing set of improvements. Backporting them
is not practical.
** Changed in: horizon
Status: New = Won't Fix
--
You received this bug notification because you are a member of Yahoo!
I believe that change in Neutron fixed this, so no change is needed in
Horizon.
** Changed in: horizon
Importance: Medium = Undecided
** Changed in: horizon
Status: Confirmed = Invalid
** Changed in: horizon
Milestone: havana-3 = None
** Changed in: horizon
Assignee: Tatiana
28, 2013 1:58 AM
To: Gabriel Hurley
Cc: OpenStack Development Mailing List; Dolph Mathews; Adam Young
Subject: [keystone][horizon]Backend filtering in Keystone
Hi Gabriel,
Following up on our discussions on filtering and pagination, here's where we
stand:
1) We have a patch ready to go into H
If you look at the code in the post()[1] method of the base workflow view
you'll note that a response to a successful workflow POST is always a
redirect[2] (caveat for when it's specifically adding data back to a field,
which isn't relevant here).
The reason for this is that in general when
I have been one of the earliest, loudest, and most consistent PITA's about
pagination, so I probably oughta speak up. I would like to state three facts:
1. Marker + limit (e.g. forward-only) pagination is horrific for building a
user interface.
2. Pagination doesn't scale.
3. OpenStack's APIs
The short answer is: you can test and develop it locally but you cannot push
it upstream until you get the dependencies released. As much as that may be
frustrating, it prevents an enormous amount of pain which OpenStack has gone
through in the past when things fail to be released as expected.
I can't reproduce this without intentionally misconfiguring things or
shoving hacks in. Please re-open if you can provide a solid repro.
Thanks for the report!
** Changed in: horizon
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
From the description I'm 95% certain this is an issue on the glance end
of things. If I'm wrong, please re-open it for Horizon.
** Also affects: glance
Importance: Undecided
Status: New
** Changed in: horizon
Status: New = Invalid
--
You received this bug notification because
Generally spot-on with what Adrian said, but I have one question from that
email:
Mappings is one of the high level concepts in CFN that I think can be
completely eliminated with auto-discovery.
What do you mean by this? What kind of autodiscovery, and where? I'm all for
eliminating mappings
I spent a bunch of time working with and understanding Heat in H2, and I find
myself with one overarching question which I wonder if anyone's thought about
or even answered already...
At present, the CloudFormation template format is the first-class means of
doing things in Heat.
I responded on the ticket as well, but here’s my take:
An error like this should absolutely be caught before it raises a database
error. A useful, human-friendly error message should be returned via the API.
Any uncaught exception is a bug. On the other side of the equation, anything
using the
Brooklyn Chen, Julie Pichon and others have already been putting in a lot of
effort in this area. I suggest you check out
https://blueprints.launchpad.net/horizon/+spec/ceilometer and sync up with them
if you're interested in proceeding.
- Gabriel
-Original Message-
From:
I've been hoping some of the more design-oriented folks would weigh in on this
issue, but that hasn't particularly happened...
My concern is that as engineers we're all comfortable with GitHub, but that it
will end up being an impediment or discouragement for people who fall more on
the
Horizon displays the data provided by Nova's API, so I strongly suspect
this may be a problem with what Nova is returning. Can you enable debug
logging for the client (or use python-novaclient directly) to do a
server list command and provide the returned data?
** Changed in: horizon
** Changed in: horizon
Status: New = Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1181150
Title:
Dashboard GUI down (HTTP 500 error) on upgrade from folsom to grizzly
To manage
, or it could be missing altogether (I believe the
client falls back to the auth URL if it fails to get the necessary data
from the service catalog).
** Changed in: horizon
Status: New = Invalid
** Changed in: horizon
Assignee: (unassigned) = Gabriel Hurley (gabriel-hurley)
--
You received
of allow project
membership assignment during user creation and we can triage it as a
significant feature addition for a future release. There's no bug here,
however.
** Changed in: horizon
Status: New = Won't Fix
** Changed in: horizon
Assignee: (unassigned) = Gabriel Hurley (gabriel
7:41 AM
To: Gabriel Hurley
Cc: Devendra Gupta; openstack@lists.launchpad.net
Subject: Re: [Openstack] API version in Grizzly
On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote:
In Grizzly I can send Keystone requests to either
http
When you say Identity v3.0 development is going on side-by-side so I think if
I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity
v3.0
with Grizzly when new version is available in updates.
Though I might have option to upgrade it or not? OR Identity v3.0 will be
If that config option is not being respected for the Nova API calls that's a
bug. Please file a ticket on Launchpad so we can track fixing it.
Thanks!
- Gabriel
From: Openstack
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Wyllys Ingersoll
If you have Instances Volumes then you're not running Grizzly Horizon.
Those two were split apart in Grizzly. Prior to Grizzly the Volume Service was
required. In Grizzly Horizon it's not.
As such you have two choices: run Cinder like you are but don't use it, or
upgrade so you're actually
There's something very wrong is false doesn't raise an exception. In Python
False is a Boolean value, false is a variable name which should be
undefined.
That aside, you should set COMPRESS_OFFLINE=False in your
openstack_dashboard/local/local_settings.py file.
- Gabriel
-Original
Identity service has both a v2.0 and v3 side-by-side. There isn't necessarily a
default except for the fact that most people's Service Catalogs still say
v2.0 in them because they're hard-coded that way.
In the future I believe the api.openstack.org site would gain a lot by storing
,
- Gabriel
From: annegen...@justwriteclick.com [mailto:annegen...@justwriteclick.com] On
Behalf Of Anne Gentle
Sent: Wednesday, May 08, 2013 4:38 PM
To: Gabriel Hurley
Cc: Devendra Gupta; openstack@lists.launchpad.net
Subject: Re: [Openstack] API version in Grizzly
On Wed, May 8, 2013 at 4:54 PM
Do you have plans to add comparison matrices, user counts, github stats,
categories (aside from arbitrary tags), etc.? No offense meant to stackmeat,
but the OpenComparison project is way ahead in terms of features that make it
easy for consumers to make educated choices about the
+1. And I'd add that we need to do everything in our collective power to treat
OpenStack as a coherent whole, not as a loosely federated set of projects that
are released together.
We are still a young community, but doing things to build supporting tools,
expose commonalities and overlaps,
I'll throw it out there again:
We really ought to deploy an OpenComparison site (http://opencomparison.org/)
for OpenStack. It's awesome, and does massive amounts of goodness for managed
information and discovery.
- Gabriel
-Original Message-
From: Openstack [mailto:openstack-
We landed a fix in Horizon yesterday ( tracked in
https://bugs.launchpad.net/horizon/+bug/1155876 ) that addresses this problem
for the Grizzly RC.
Nova should have followed a proper deprecation path here and accepted the
parameters in this release and reject them (if they really must) in
I have tested the latest master against IE10 and it displays exactly as
expected (see screenshot). I'm targeting this against the Ubuntu distro
to see if they have any input on what's amiss in their repo.
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Changed
** Attachment added: Screenshot of latest master in IE10
https://bugs.launchpad.net/horizon/+bug/1156742/+attachment/3582323/+files/ie10.png
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to horizon in Ubuntu.
** Attachment added: Screenshot of latest master in IE10
https://bugs.launchpad.net/horizon/+bug/1156742/+attachment/3582323/+files/ie10.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1156742
I have tested the latest master against IE10 and it displays exactly as
expected (see screenshot). I'm targeting this against the Ubuntu distro
to see if they have any input on what's amiss in their repo.
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Changed
I have tested the latest master against IE10 and it displays exactly as
expected (see screenshot). I'm targeting this against the Ubuntu distro
to see if they have any input on what's amiss in their repo.
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Changed
Hi folks!
I'm nominating myself for Horizon PTL for another term. I want to continue
fighting for cross-service integration/standardization, better APIs for
everyone, and the best possible user interface to introduce people to what
OpenStack can do.
Quick recap of my qualifications: current
This bug is caused by an outdated version of django compressor in the
ubuntu apt repo. It should not be fixed in Horizon master.
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Changed in: horizon
Importance: High = Undecided
** Changed in: horizon
This bug is caused by an outdated version of django compressor in the
ubuntu apt repo. It should not be fixed in Horizon master.
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Changed in: horizon
Importance: High = Undecided
** Changed in: horizon
This bug is caused by an outdated version of django compressor in the
ubuntu apt repo. It should not be fixed in Horizon master.
** Also affects: horizon (Ubuntu)
Importance: Undecided
Status: New
** Changed in: horizon
Importance: High = Undecided
** Changed in: horizon
That particular endpoint not found log message is a red herring. It's been
removed in keystoneclient trunk because it was logging an *expected* error.
There isn't supposed to be a service catalog available at the point at which it
logged that message, and it lead to confusion just like this.
This was fixed in master, the bug report is for Folsom.
** Changed in: horizon
Importance: High = Undecided
** Changed in: horizon
Status: Confirmed = Invalid
** Changed in: horizon
Milestone: grizzly-3 = None
--
You received this bug notification because you are a member of
This has been all fixed in Grizzly, but the scope involved in
backporting all the patches that were necessary makes me disinclined to
do so. It would require backporting all of the following to avoid
rehashing the entire trail of issues that had to be resolved for this:
Superseded by this blueprint:
https://blueprints.launchpad.net/horizon/+spec/swift-folder-prefix
** Changed in: horizon
Importance: Wishlist = Undecided
** Changed in: horizon
Status: Confirmed = Won't Fix
** Changed in: horizon
Milestone: grizzly-3 = None
--
You received this
Even though I don't experience this problem (and prefer nginx to apache), I can
help diagnose:
Connections ending up in CLOSE_WAIT means that the socket isn't being fully
closed, which is controlled by the client lib (in this case
python-keystoneclient) which uses httplib2 under the hood.
Also, aren't the release names always *California* cities? Thereby Hillsboro,
Oregon isn't a valid choice...
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Poll: H release cycle naming
Also, aren't the release names always *California* cities?
Nope. =)
http://wiki.openstack.org/ReleaseNaming
At Your Service,
--
Mark T. Voelker
On 1/28/13 3:23 PM, Gabriel Hurley wrote:
Also
Horizon's list of required services includes Nova, Glance and Keystone. At
present no work has been done to make it run with a Swift + Keystone (only)
configuration. That said, it's not impossible. The easiest route would likely
be to unregister all of the Nova and Glance-related panels in the
I haven't heard a report like this from anyone else. Looking at your patch it
looks like you're having problems with the sub-module imports for some reason,
which sounds to me like a Python problem. Is there anything unusual about your
version of Python? Any unusual/duplicate packages on your
The DevStack and Ubuntu configurations run with the Ubuntu distro's default
version of Apache and modWSGI. Personally I'm also a big fan of NginX. Horizon,
being a Django/WSGI-compliant application can run behind any webserver that
supports the Python WSGI standard.
- Gabriel
Have you tried doing what it said and running manage.py compress? (make sure
you're in the proper Python environment/venv when running that command)
That error indicates one of two things:
1. You have your settings set with COMPRESS_ENABLED = True and
COMPRESS_OFFLINE = True but you
It sounds like you *could* start updating and submitting it, but with the
knowledge that you’ll have to continue to tweak it just as the JSON spec is
being tweaked during development. So your options are to maintain it as such or
wait until it’s declared FINAL and then do the work later on but
Probably valid for the ubuntu distro, but not for Horizon since this
code doesn't exist in the main project.
** Changed in: horizon
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to horizon in Ubuntu.
Probably valid for the ubuntu distro, but not for Horizon since this
code doesn't exist in the main project.
** Changed in: horizon
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
1 - 100 of 391 matches
Mail list logo
