smolt-devel

smolt-devel@lists.fedorahosted.org

12 discussions

Smolt patches and GSoC 2011
by Max Usachev 18 Apr '11

18 Apr '11

Hi, guys! I want to participate in GSoC this year and work on Smolt project. I have strong skills in Python programming and UI developing using PyGTK. As I mentioned in IRC, I have discussed it with Vincent, cause he is mentor of this project, and he suggested me to connect with Smolt developers. I have cloned smolt git repository and commit some patches to my repo: git://github.com/umax/smolt.git It's small patches, but nevertheless. I also have some ideas how to improve Smolt: 1) Create separate module, which will gathering device information and create program interface for it. This module should control, what information use: dbus, dmidecode and others. In feature, we also can reimplement as plugins. 2) In RedHad distro, program craches if there is no configuration file in /etc/smolt, so we should create this file with default values if it doesn't exist. 3) UI improvements and of course, new GTK UI. 4) Code cleaning and redesigning. Let's discuss it before GSoC starts and we can make SMolt the best program for gathering device info and make it as standard for linux distros! Looking forward to you comments and suggestions! Br, Max Usachev aka plastun.

1 0

New client gui
by Mads Villadsen 12 May '09

12 May '09

I have been working on a new smoltGui, and I now feel I have something that is ready for people to look at. I am now developing it in a local git branch, and if there is any interest in it I can create a smolt project on gitorious, and upload it there. I have attached patches against the git version if anyone wants to try it out. Suggestions and comments are very welcome. -- Mads Villadsen <maxx(a)krakoa.dk>

1 0

Re: Follow up from LinuxTag
by Yaakov Nemoy 04 Jun '08

04 Jun '08

On Wed, Jun 4, 2008 at 2:24 PM, Klaas Freitag <freitag(a)suse.de> wrote: > On Montag, 2. Juni 2008, Yaakov Nemoy wrote: > > Hi Yaakov, >> >> I would like to follow up with you all the details we discussed at >> LinuxTag last Saturday and a couple of other details to mention. > Thanks for driving that. No Problem >> 1) Smolt will be an optional package in 11.0 >> - We discussed writing something in the wiki on a Howto to get >> powerusers to test out the code. This will help iron out bugs. Where >> would I begin putting in such an article. > I started a page in the openSUSE wiki under > http://en.opensuse.org/Hardware/Smolt > You're very welcome to contribute. Will do. >> 3) We (the smolt development team) are more than happy to accept patches >> - Copyright attribution should be made to Michael McGrath, we stick >> to a GPLv2+ license, and will announce a head of time if we need to >> change our licensing. >> - Under the European 'droit d'auteur', I think we just need an >> unlimited rights license that can't be revoked so long as it does not >> infringe on the author's rights. If you are not familiar with the >> details behind these things, we'll have to check with our lawyers. >> - The best thing to do is to use git's tools to send us the patches. >> This let's us track the author attribution more easily. If your team >> is not familiar with git, I would be more than happy to assist them. > Hmm, not sure about the Copyright assignement at the moment. For small > patches that's obviously no prob, so let's take care about that when we > get there. Fine. I just needed to give you a heads up warning. >> 4) openSuSE is more than welcome to use our server hosted at >> smolts.org to send data. > That's great. How is that organised? Is smolts.org Fedora? Are there > plans to make it independant from Fedora and drive it as it's own > community project? Might attract other linux projets that way... > Maybe together we could find sponsoring from big players like HP etc. > for that? Smolt was developed by Mike before he became a Red Hat employee. We host the development and operation on Red Hat/Fedora servers, with the effort of the Fedora Infrastructure team. Officially, though, we treat Smolt like it were an upstream project. For now, I think we're content to continue having Fedora host our stuff, since it would be a lot of work to distribute the load. Mike got the 'smolts.org' domain specifically so we wouldn't have a fedora related URL. > Another thing: Would you agree to make smolts.org look even less like > Fedora as we're starting to use it together? You already did a lot but > why not have a own color for smolts for example? Would you be open > for that? We rather like the colour blue, and there aren't many colors that are distro-independent. Actually, I'm not as an artistic person as I would like to be, and can't really come up with a new theme myself. I have no problems changing the theme. Perhaps we should have our artwork teams collaborate on something? >> - We should be making releases of the data available to the public, >> stripped of private information. For your own purposes, I believe >> this will give you the best data during the summer. > Public releases of anonym data are fine. OTOH we would like to have > the possibility to access the data anytime - and make our data analysis > as well. Is that possible? I'll defer to Mike on how often he plans on making the public releases. I think once a week is reasonable. You can import the data into mysql, and run any sql query you want on it. If you need the actual data more frequently, you will have to speak to Mike. mfG, Yaakov

1 0

running smoon with python 2.4
by Thomas Schmidt 04 Jun '08

04 Jun '08

Hi, I wrote a little patch that allows running the smoon server in a python 2.4 environment. Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001)

4 5

Some changes to Smolt infrastructure
by Yaakov Nemoy 21 May '08

21 May '08

Hey all, First of all, most of you should be on the mailing list, but I get the suspicion that some of you are missing. I forwarded some information about Pavel, our new GSoC student to the list, and it was surprisingly quiet and bikeshed-painting discussion free. (Maybe that's a good thing....). Anyways, these changes are important, so I'm spamming all of you to make sure it gets to the right people. Toshio and Luke, I included you two in on this for webdev reasons. You might be interested. Btw, the mailing list can be found at: https://fedorahosted.org/mailman/listinfo/smolt-devel So i've (poorly) implemented a change we should have had 4 months ago. Namely, I've set up a script that will patch updates into the database only if the updates havent't already been patched in. This means a few new rules and concepts for us to work with. 1) We will have a new version numbering scheme. The Smolt program will continue to use the major.minor.point.subpoint scheme as before. The database will incorporate a similar major.minor.point numbering scheme independent of the Smolt program. Every change to the database will get a version number bump. Period. When you make a change to the database, be sure to use git to tag your commit with a tag such as 'db1.3.0' or 'db12.40.2'. Ideally, I would like to see every significant release receive a full major number bump. (Significant is probably when Mike upgrades the server :P) 2) I lied. Actually, the naming scheme should be major.minor.point.branch.description, ie db1.3.4.main.hal.version or db2.34.2.somebranch.experimental.optimization . The regular expression that parses the version number is: r'db([0-9]*)\.([0-9]*)\.([0-9]*)\.(\w*)\.(.*)sql$' 3) You will conveniently notice the 'sql$' at the end of that regex. That's because new changes will go into a file in /databases named accordingly. Making changes is actually quite simple. Pick a new revision number in sequence, create a file named after it, insert your changes, and save. The script /smoon/update-database.py should be able to figure out the rest. (I say should, because there are still a few bugs.) On a side note, don't leave the file empty. SQLalchemy will complain loudly and rudely. 4) To start development anew, first import the initial DDL file. I'm not sure what we're going to name it, but I think I see a bikeshed that needs painting. Then run update-database.py. Magic, wow! 5) To get a partially up to date database up to speed, do not import the initiall DDL file. Just run update-database.py. 6) One more note, don't name the branch anything but 'main'. You will notice in an article I will post below, that there is a question of the best way to handle branching and merging. I still need to give this thought. I included the 'branch' field into the infrastructure because it is very difficult to fix. Since that table needs to be present in the database before the script can run, we would need an older version of update-database.py to upgrade to a newer version. For the sake of argument, any changes to the table schema_changes ar probably bad. The inspiration for this scheme came from this article. Sometimes it pays to keep up with the closed source development side of things ;). (Coding Horror is actually a really fascinating blog.) http://www.codinghorror.com/blog/archives/001050.html Some notes to specific people. Ricky, Toshio, Luke, I'm not sure how useful this is to the rest of the Infrastructure team, but please feel free to pillage. I'm sure this needs a few more eyes going over it. Pavel, For your summer work, I want you to feel free to consider any additions you want to make to the database, for example metadata tables, or user added information. As per the GSoC stuff, you can send me SQL code that will upgrade the database, and I will include it into the main branch. Then, you should rebase your private branch on top of the new main branch, using git. This way, your weekly patchset will apply directly on top of our changes. -Yaakov PS, should I post this to some other fedora mailing list too?

2 1

Fwd: Smolt GSoC: Planning Stage 1
by Yaakov Nemoy 16 May '08

16 May '08

I'm going to forward this to the Smolt development list, so they can comment. ---------- Forwarded message ---------- From: Pavel Khardikov <pavel.khardikov(a)gmail.com> Date: Thu, May 15, 2008 at 4:00 PM Subject: Re: Smolt GSoC: Planning Stage 1 To: Yaakov Nemoy <loupgaroublond(a)gmail.com> Hi Yaakov, If you don't mind, I would like to write about how I see the process work on the project this summer. I do not know how it will be correct but it would be easier for me to work that way. So It will be very important to know what do you think about this. 1 -- We'll choose AJAX components, JS libraries and widgets that will be used to presentation data on pages. 2 -- Then I will make sketches of all pages in a vector editor like the one that I showed you with my GSoC proposal. You'll look at them and say your opinion about them on the basis of which we'll continue to work on. At the design stage of the WebUI I must know exactly what AJAX components, JS libraries and widgets, I'll use, so that my sketches will be most similar to how web pages will look then. To build different types of schedules, I would like to use Flash Chart. If you are not against it. IMHO Flash allows to provide datum more convenient and clear to user. In addition, there is confidence that Flash sites will be properly displayed in all browsers and on different platforms. I think this is an important moment. There are a lot of videos (Flash Video) in the network, it's difficult to imagine a user without flash plug-in in his browser. I tried to look on site http://smolts.org with different browsers, namely: Safari 3.0.4 and opera 9.26 win32 - screens are in the attachment to the letter. As I understand all the libraries and components which I'll use must be open source? Or am I wrong? There are 2 version of Flash Chart that I liked: * http://teethgrinder.co.uk/open-flash-chart/ - open source * http://www.amcharts.com/ - commercial license I would like to hear what do you think about this? 3 -- After all the sketches are created I turn to creating templates of web pages (HTML + JS + CSS + Flash). The most important thing at this stage will be writing valid HTML + CSS code which will be equally and properly displayed in different browsers and on different platforms. Therefore, It would be very convenient and useful to have deployed locally Smoon server to have an opportunity, quickly and easily modify HTML and CSS code and view the results in different browsers and on different platforms. 4 -- I don't think that would need to change the structure or design of your database. My task is to make a pretty Web 2.0 Interface that is to create a new View (UI). That is, in my opinion amount of datum provided to the user will not change and will change only the format of their presentation. 5 -- At this stage I would fill html templates with necessary datum, make and build a tag cloud charts based on data from the database. At this stage I have learned the TurboGears, Genshi, SQLAlchemy, etc ... 6 -- When most of these tasks will be done I will make my server public via the Internet so you can look at the results and evaluate it. Then we can begin to add new features, documentation for users, etc ... After I run the server Smoon locally and get any part of the database from you I'll immediately begin to do this consistently. As my work, I will give you all my changes compared with the current version smoon. -- Best regards. Pavel Khardikov

1 1

Problem setting up smoon
by Thomas Schmidt 24 Apr '08

24 Apr '08

Hi, I am trying to setup a smoon server on openSUSE 10.3 from the 1.1.1.1 release. I changed the dev.cfg to use a mysql backend. When running: smoltSendProfile -as http://localhost:8080 I get: "An error has occured while contacting the server: [Errno 14] HTTP Error 500: Internal error" the server log is attached. Checking the HTTP traffic shows that the /tokens/token_json?uuid=... call returns successful. Also the POST to /client/add_json returns with a HTML page containing a pub uuid, but there is nothing stored to the database, I cannot see an UPDATE or INSERT statement in the log. The third call /tokens/admin_token_json?uuid=... then fails because it can not lookup the uuid from db. Has somebody an idea what could go wrong here? Greetings -- Thomas Schmidt (tschmidt [at] suse.de) SUSE Linux Products GmbH :: Research & Development :: Internal Tools "Don't Panic", Douglas Adams (1952 - 11.05.2001)

2 7

Smolt on i686
by Mike McGrath 10 Apr '08

10 Apr '08

Hey guys, I just wanted to let everyone know I'm in the process of moving smolts.org servers from x86_64 to i686. This is mostly to keep memory usage down (which it does very well) and we're not getting any benefits from running smolt on x86_64 anyway. -Mike

2 2

Upcoming Meeting
by Yaakov Nemoy 07 Mar '08

07 Mar '08

Hey List, I want to have this meeting sometime monday, preferably in the morning if the SuSE guys ever respond. (I'm not sure they will though.) Please comment on it. http://fedoraproject.org/wiki/YaakovNemoy/Smolt/Meetings/2008-03-10-Meeting… -Yaakov

2 1

test 3
by Jeffrey Ollie 07 Mar '08

07 Mar '08

test 3

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

smolt-devel