FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-29-2008, 12:27 AM
Ignacio Vazquez-Abrams
 
Default

-------- Forwarded Message --------
> From: Kay Williams <kwilliams@renditionsoftware.com>
> To: webmaster@fedoraproject.org
> Subject: broken artwork page
> Date: Wed, 28 May 2008 16:44:32 -0700
>
> Hello,
>
> The wiki page below seems to be broken.
>
> http://fedoraproject.org/wiki/Artwork/ThemingOverview#Artwork_seen_during_in
> stallation
>
> Instead of showing inline images, it is showing wiki syntax, e.g.
>
> [[Image:Artwork_ThemingOverview_||<^ |7>
> [[Image:Artwork_ThemingOverview_07GDM.png] ||<^ style="color: #636363;">
> Description: || Login Screen. ||
>
> Thanks,
> Kay

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
_______________________________________________
Fedora-art-list mailing list
Fedora-art-list@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-art-list
 
Old 05-30-2008, 01:45 PM
Luke Macken
 
Default

On Thu, May 15, 2008 at 11:24:59AM -0400, John (J5) Palmieri wrote:
> On Wed, 2008-05-14 at 12:39 -0400, Luke Macken wrote:
> > On Wed, May 14, 2008 at 09:06:24AM -0700, Toshio Kuratomi wrote:
> > > Forwarding to fedora-infrastructure-list soit canget more exposure and
> > > discussion.
> > >
> > > -------- Original Message --------
> > > Subject: Tosca widgets, only half the battle
> > > Date: Sun, 11 May 2008 12:27:36 -0400
> > > From: John (J5) Palmieri <johnp@redhat.com>
> > > To: Toshio Kuratomi <a.badger@gmail.com>
> > > CC: tcallawa@redhat.com, lmacken@redhat.com, mmcgrath@redhat.com
> > >
> > > After hacking away at MyFedora and producing a lot of ugly code in the
> > > process I finally sat down the last two weeks to organize everything
> > > into a framework make it much more extensible and have patterns for
> > > people to easily create content. Most of the technologies are
> > > solidifying into my head and I have been working on hashing out an API
> > > design behind the user interaction design I had started with. The issue
> > > I am running into now is the fact that Turbo Gears and related
> > > technology come from a monolithic design and adhere too stringently to
> > > the Model/View/Controller design pattern. This is really an issue when
> > > your models, views and controllers can come from different applications
> > > or even different servers. MyFedora is of course a mashup of different
> > > tools and does not fit the, I'm grabbing data from a single database and
> > > displaying it via a self contained template, mold. What I need is a
> > > complete plugin system where a person can write their own self contained
> > > controllers, templates and static files which then drop in and are
> > > loaded on the fly, while integrating with the global project.
> > >
> > > Before I go further let me describe my design.
> > >
> > > Vocabulary:
> > >
> > > Resource - This is the starting point for MyFedora plugins. A resource
> > > is any abstract grouping such as "packages", "people" and "projects"
> > > which contain tools for viewing and manipulating data within the
> > > resource's context.
> > >
> > > Tools - A tool is a web app for viewing or manipulating data. For
> > > example Builds would be a tool for the package resource.
> > >
> > > Data Id - The data id is a pointer to a specific dataset the tools work
> > > on. For example the package resource considers each fedora package name
> > > to be a data_id.
> > >
> > > The way things work are Resources are placed in the resources/ directory
> > > and contain the logic for routing requests to a specific tool. They
> > > also contain the master template which is a cause of path problems with
> > > the current TG setup (include paths are relative to the including
> > > template)
> > >
> > > Tools are placed in the tools/ directory and are controllers just like
> > > any other TG controller. The exception is there is a standard for
> > > including the master template and the tool pulls templates and static
> > > files from its own directory. Tools can register with more than one
> > > resource and must modify its behavior based on the resource calling it.
> > > For instance the Build tool would be able to register with the package
> > > and people resource and depending which resource is being used it would
> > > display either a specific person's builds or the build history of a
> > > package. Based on the resource being used the master template is pulled
> > > in by the tool's templates.
> > >
> > > Data id's are simply what the resource passes to the tool and the tool
> > > needs to be able to accept when dealing with a particular resource. For
> > > instance the Packages resource would send a package name as a data id
> > > and the Peoples resource would send a person's FAS username.
> > >
> > > The issue here is I need the tools to be self contained but still
> > > integrate correctly with the global assests such as master templates and
> > > graphics. Tosca widgets seemed to be the answer until I looked further
> > > and found out they are just a higher level display layer than a self
> > > contained controller/template system. It seems to be confusing because
> > > it breaks the connection between the controller, data and the display
> > > when I want that all to be encapsulated. Basically I don't want the
> > > master page dolling out the data because the master page is just a
> > > container to display the tool and links to other tools. The tools
> > > should know where to get their data from.
> > >
> > > One solution is to use ToscaWidgets as a replacement for templates (or
> > > more apt another layer between the controller and the template). That
> > > makes things more complicated and throws away a lot of the concepts of
> > > TG controllers. I guess I am probably just hung up on how I first
> > > learned TG and we can just document around those issues. But another
> > > thing to think about is stuff like WSGI.
> > >
> > > What do you guys think? Given my design and goals such as the ability to
> > > display tools on the portal page, what is our plan of attack? How do we
> > > concoct a plugin system to make it easy for others to create integrated
> > > content while really just concentrating on their bits and not the wider
> > > integration infrastructure? Are there systems/libraries out there that
> > > already do this? Tosca is only part of the solution because it only
> > > deals with encapsulating display and is mostly geared to generic widgets
> > > like lists and not complete pages. I would like to have a framework
> > > that is simple, focused and easy to use.
> >
> > You mention that you're running into issues with TurboGears v1.0's
> > "monolithic design", which makes various assumptions about how your
> > application is going to be implemented. I agree that this may not be
> > ideal for the MyFedora environment, which is why I think basing this on
> > TurboGears v2.0 is the way to go. Being built on top of Pylons, which
> > does not make these strict assumptions, it will allow us to have much
> > more control over how our application stack is structured. Since
> > TG2/Pylons leverages the WSGI standard (which we are starting to adopt
> > in our infrastructure deployment already), it will allow us to change
> > any part of our own stack at any time, without taking apart the whole
> > framework. If we treat resources as WSGI applications/middleware, it
> > will make it trivial to plug these into our framework, package them, and
> > develop them in isolation.
> >
> > ToscaWidgets is extremely useful, but not at this low of a level in our
> > framework design. I think that TW will be great for the high-level
> > re-usable widgets that can potentially use various MyFedora
> > resources/tools, but for core MyFedora resources, I think basing them on
> > top of the WSGI standard will be the most flexible solution.
>
> I was thinking that but I am still not sure what WSGI is. Right now it
> is just a magic term to me. Can you describe them in terms of
> controllers right now? How does relative paths work (for instance with
> template inheritance)? Is TG 2.0 stable enough for me to start rebasing
> on?

So, in terms of controller dispatching, they use two different
mechanisms. TurboGears 1.0 uses CherryPy's object dispatch, which is
essentially an attribute lookup for each path segment. Pylons uses
Route's pattern matching against the full path to determine the
controller to dispatch to.

Basically, TurboGears object dispatching points to a function that is invoked by
CherryPy, where Pylons points to a WSGI application.

Since we're already using Routes for MyFedora, the switch to TG2 seems
quite logical. TurboGears2 will use a more flexible object-dispatching system,
and will also support direct Routes integration as well.

For a great comparison of TurboGears (1.0) to Pylons, I recommend
checking out this blog post by Ian Bicking:

http://blog.ianbicking.org/turbogears-and-pylons.html

luke

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 05-30-2008, 07:26 PM
"Arifur Rahman"
 
Default

hi!
i have been using fedora since 2005. i like this very mouch and i alwas encorage my friends to use it.
it was my dream to be one of the fedora contributores and now i am here. But dont know how to start.
i have knowledge on

**************************** administrative level,
* * * * * * * * * * * * * ** server configuration,
**************************** shell scripting,
**************************** C, assembly language.
now i am studying on kernel and in the very primary level.

please give me some advice how can i start as a contributor, how can i get a project that should be done to develop fedora and which is within my ability.

On Fri, May 30, 2008 at 7:45 PM, Luke Macken <lmacken@redhat.com> wrote:

On Thu, May 15, 2008 at 11:24:59AM -0400, John (J5) Palmieri wrote:

> On Wed, 2008-05-14 at 12:39 -0400, Luke Macken wrote:

> > On Wed, May 14, 2008 at 09:06:24AM -0700, Toshio Kuratomi wrote:

> > > Forwarding to fedora-infrastructure-list soit canget more exposure and

> > > discussion.

> > >

> > > -------- Original Message --------

> > > Subject: Tosca widgets, only half the battle

> > > Date: Sun, 11 May 2008 12:27:36 -0400

> > > From: John (J5) Palmieri <johnp@redhat.com>

> > > To: Toshio Kuratomi <a.badger@gmail.com>

> > > CC: tcallawa@redhat.com, lmacken@redhat.com, mmcgrath@redhat.com

> > >

> > > After hacking away at MyFedora and producing a lot of ugly code in the

> > > process I finally sat down the last two weeks to organize everything

> > > into a framework make it much more extensible and have patterns for

> > > people to easily create content. *Most of the technologies are

> > > solidifying into my head and I have been working on hashing out an API

> > > design behind the user interaction design I had started with. *The issue

> > > I am running into now is the fact that Turbo Gears and related

> > > technology come from a monolithic design and adhere too stringently to

> > > the Model/View/Controller design pattern. *This is really an issue when

> > > your models, views and controllers can come from different applications

> > > or even different servers. *MyFedora is of course a mashup of different

> > > tools and does not fit the, I'm grabbing data from a single database and

> > > displaying it via a self contained template, mold. *What I need is a

> > > complete plugin system where a person can write their own self contained

> > > controllers, templates and static files which then drop in and are

> > > loaded on the fly, while integrating with the global project.

> > >

> > > Before I go further let me describe my design.

> > >

> > > Vocabulary:

> > >

> > > Resource - This is the starting point for MyFedora plugins. *A resource

> > > is any abstract grouping such as "packages", "people" and "projects"

> > > which contain tools for viewing and manipulating data within the

> > > resource's context.

> > >

> > > Tools - A tool is a web app for viewing or manipulating data. *For

> > > example Builds would be a tool for the package resource.

> > >

> > > Data Id - The data id is a pointer to a specific dataset the tools work

> > > on. *For example the package resource considers each fedora package name

> > > to be a data_id.

> > >

> > > The way things work are Resources are placed in the resources/ directory

> > > and contain the logic for routing requests to a specific tool. *They

> > > also contain the master template which is a cause of path problems with

> > > the current TG setup (include paths are relative to the including

> > > template)

> > >

> > > Tools are placed in the tools/ directory and are controllers just like

> > > any other TG controller. *The exception is there is a standard for

> > > including the master template and the tool pulls templates and static

> > > files from its own directory. *Tools can register with more than one

> > > resource and must modify its behavior based on the resource calling it.

> > > For instance the Build tool would be able to register with the package

> > > and people resource and depending which resource is being used it would

> > > display either a specific person's builds or the build history of a

> > > package. *Based on the resource being used the master template is pulled

> > > in by the tool's templates.

> > >

> > > Data id's are simply what the resource passes to the tool and the tool

> > > needs to be able to accept when dealing with a particular resource. *For

> > > instance the Packages resource would send a package name as a data id

> > > and the Peoples resource would send a person's FAS username.

> > >

> > > The issue here is I need the tools to be self contained but still

> > > integrate correctly with the global assests such as master templates and

> > > graphics. *Tosca widgets seemed to be the answer until I looked further

> > > and found out they are just a higher level display layer than a self

> > > contained controller/template system. *It seems to be confusing because

> > > it breaks the connection between the controller, data and the display

> > > when I want that all to be encapsulated. *Basically I don't want the

> > > master page dolling out the data because the master page is just a

> > > container to display the tool and links to other tools. *The tools

> > > should know where to get their data from.

> > >

> > > One solution is to use ToscaWidgets as a replacement for templates (or

> > > more apt another layer between the controller and the template). *That

> > > makes things more complicated and throws away a lot of the concepts of

> > > TG controllers. *I guess I am probably just hung up on how I first

> > > learned TG and we can just document around those issues. *But another

> > > thing to think about is stuff like WSGI.

> > >

> > > What do you guys think? Given my design and goals such as the ability to

> > > display tools on the portal page, what is our plan of attack? *How do we

> > > concoct a plugin system to make it easy for others to create integrated

> > > content while really just concentrating on their bits and not the wider

> > > integration infrastructure? *Are there systems/libraries out there that

> > > already do this? Tosca is only part of the solution because it only

> > > deals with encapsulating display and is mostly geared to generic widgets

> > > like lists and not complete pages. *I would like to have a framework

> > > that is simple, focused and easy to use.

> >

> > You mention that you're running into issues with TurboGears v1.0's

> > "monolithic design", which makes various assumptions about how your

> > application is going to be implemented. *I agree that this may not be

> > ideal for the MyFedora environment, which is why I think basing this on

> > TurboGears v2.0 is the way to go. *Being built on top of Pylons, which

> > does not make these strict assumptions, it will allow us to have much

> > more control over how our application stack is structured. *Since

> > TG2/Pylons leverages the WSGI standard (which we are starting to adopt

> > in our infrastructure deployment already), it will allow us to change

> > any part of our own stack at any time, without taking apart the whole

> > framework. *If we treat resources as WSGI applications/middleware, it

> > will make it trivial to plug these into our framework, package them, and

> > develop them in isolation.

> >

> > ToscaWidgets is extremely useful, but not at this low of a level in our

> > framework design. *I think that TW will be great for the high-level

> > re-usable widgets that can potentially use various MyFedora

> > resources/tools, but for core MyFedora resources, I think basing them on

> > top of the WSGI standard will be the most flexible solution.

>

> I was thinking that but I am still not sure what WSGI is. *Right now it

> is just a magic term to me. *Can you describe them in terms of

> controllers right now? *How does relative paths work (for instance with

> template inheritance)? Is TG 2.0 stable enough for me to start rebasing

> on?



So, in terms of controller dispatching, they use two different

mechanisms. *TurboGears 1.0 uses CherryPy's object dispatch, which is

essentially an attribute lookup for each path segment. *Pylons uses

Route's pattern matching against the full path to determine the

controller to dispatch to.



Basically, TurboGears object dispatching points to a function that is invoked by

CherryPy, where Pylons points to a WSGI application.



Since we're already using Routes for MyFedora, the switch to TG2 seems

quite logical. *TurboGears2 will use a more flexible object-dispatching system,

and will also support direct Routes integration as well.



For a great comparison of TurboGears (1.0) to Pylons, I recommend

checking out this blog post by Ian Bicking:



* *http://blog.ianbicking.org/turbogears-and-pylons.html



luke



_______________________________________________

Fedora-infrastructure-list mailing list

Fedora-infrastructure-list@redhat.com

https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list



_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 05-31-2008, 12:35 AM
Ignacio Vazquez-Abrams
 
Default

Any ideas on this one, guys?

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 05-31-2008, 03:22 AM
"Jared Brothers"
 
Default

I see the same error.

--
Jared Brothers

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 05-31-2008, 03:47 AM
Mike McGrath
 
Default

Are you still seeing it now? If not try clearing your cookies and
restarting your browser? I made some pretty serious auth changes today
that I could imagine caused this. If the problems go away then we're ok,
the cookies for people will expire eventually. If you keep getting them
though I need to go back and re-look at some things.

-Mike

On Fri, 30 May 2008, Jared Brothers wrote:

> I see the same error.
>
> --
> Jared Brothers
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 05-31-2008, 07:05 PM
Mike McGrath
 
Default

On Fri, 30 May 2008, Ignacio Vazquez-Abrams wrote:

> Any ideas on this one, guys?
>

Figured this one out. Some alterations to our auth extension made it so
users that hadn't logged in weren't able to. I'm pushing the configs now
if it continues to happen please let me know.

-Mike

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 06-01-2008, 01:47 AM
"Jared Brothers"
 
Default

On Sat, May 31, 2008 at 3:05 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
> Figured this one out. Some alterations to our auth extension made it so
> users that hadn't logged in weren't able to. I'm pushing the configs now
> if it continues to happen please let me know.
>
> -Mike

Works for me.

Thanks,
--
Jared Brothers

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 06-02-2008, 04:32 AM
Justin Findlay
 
Default

I'm using net-misc/kiax-0.8.51 and for the past few months it has
started taking nearly a minute to startup. It's not an app that I use
very often, but still I'd like to find out why. I ran an strace on it
today and it's running thousands and thousands of this call:

fstat(6,{st_dev=makedev(254, 0), st_ino=3719182, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=500, st_gid=500, st_blksize=4096, st_blocks=216,
st_size=105243, st_atime=2008/06/01-22:15:24,
st_mtime=2008/06/01-16:27:05, st_ctime=2008/06/01-16:27:05}) = 0

This happens when I run it both locally and remotely over ssh -X. What
can I do to figure out why it's running so many of these function calls?
The inode maps to ~/.qt/kiaxrc


Justin
--
gentoo-user@lists.gentoo.org mailing list
 
Old 06-02-2008, 12:18 PM
"Bent Terp"
 
Default

On Mon, Jun 2, 2008 at 2:03 PM, Johnny Hughes <johnny@centos.org> wrote:
> I would also not use XFS in production ... but that is just me.

Interesting, I thought that XFS was fairly safe for use. What would
you recommend for filesystems in the 50-500 terabyte range?

(And yes, we do actually run a 70 TB at the moment, so I'm not asking
just to annoy you; I'm genuinely interested in your opinion as well as
those of others, so feel free to chip in)

BR Bent
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 10:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org