[ASLO] ASLO build and deployment process (Jatin Dhankhar)

Jatin Dhankhar dhankhar.jatin at gmail.com
Thu Apr 6 12:23:01 EDT 2017
Previous message (by thread): [ASLO] ASLO build and deployment process (Jatin Dhankhar)
Next message (by thread): [ASLO] ASLO build and deployment process (Jatin Dhankhar)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,

I am setting up Django now and going through some tutorials. I will setup
the code with a very basic and barebones version of what we want to achieve
and put it in a private repo. We can even host it online, since I have some
DigitalOcean credit left. Will keep you posted.

Thanks.
Jatin Dhankhar

On Thu, Apr 6, 2017 at 7:11 AM, Tony Anderson <tony_anderson at usa.net> wrote:

> Hi, Jatin
>
> In setting up Django, I think you will do it on your computer not on a
> separate server. Django handles that through its own server and has sgqlite
> as a database built-in. A good first start would be to set up the tutorial
> app (https://www.djangoproject.com/). Essentially you will need to
> install django and then set up the tutorial app 'poll'. Working through
> this tutorial will help a lot later on. The key point is that after initial
> setup, there are three important elements: url.py which defines the urls to
> access the application, views.py which is the python code that responds to
> a request by accessing the db and delivering the relevant information to a
> template. The template is an html file with variables of the form {{
> activity.name }} transferring information from the view to the template.
>
> What I have is an application: aslo. Once you have Django installed and
> have run the tutorial app through Django's server, you'll be ready.
> Essentially, you will only need to add aslo as a second app in the
> settings. One possible confusion is that DJango lives in a project -
> essentially a directory containing its manage.py admin interface. In the
> directory is another directory of the same name with the settings.py and
> url.py. The poll app is a directory in the top-level alongside the inner
> directory with the project name.
>
> For example, my project is schoolsite. So my setup looks like:
>
> /library/schoolsite/schoolsite
> /library/schoolsite/aslo
>
> Meanwhile my code links directly to an activity page with no index. I'll
> add an index so the essential structure will be there. I'll also include
> the 'fixtures' to set up a 25 activity capability. Fixtures are csv files
> from which the database (metadata) can be loaded.
>
> Tony
>
>
> On 04/06/2017 03:22 AM, Jatin Dhankhar wrote:
>
> Hi Tony,
> Hope you had a nice trip/travel.
> Sugar labs is really awesome and good looking, but I presume it's still
> under development, login and sign up section is a placeholder.
>
> Your example has each activity occupying a large part of the screen, my
>> current implementation shows the activities about like an ls listing. Sugar
>> network is a compromise between.
>
> Sorry to ask,  but which example ? We can work with someone from the
> design team and go through some mockups to decide, but we can do it later,
> since frontend should be easy to modify/
>
> One part of the challenge is that we want an interface which is easy for
>> school children to use (generally with minimal English literacy). This is
>> the basis for an emphasis on icons.
>
> Yes this should be enforced as part of guideline, all the way down to the
> activity itself (I see some popular activities lean heavy on icons)
>
> If you want to get your feet wet, I can send you the current django code
>> and we could work together in adding capabilities - step by step
>
> Yes, count me in.
>
>  So there are three strategies. One is to download the
>> download.sugarlabs.org repository (it should be open to anonymous ftp).
>> The second is to take only the current working activities (I am guessing
>> about 200-300 to start). But I would recommend a selection of 25 or so that
>> you can use to test the code.
>
> Third approach is fine by me. First approach would include all
> activities,including those which are incompatible.
>
>
> This is handled by a Pull Request system. Essentially, there is a select
>> team that merges PRs into the git commits. So I anticipate that this team
>> would 'release' updated or new activities into the 'master' branch and then
>> deploy them to ASLO.
>
> Yes, we can add a bot in between which would pre-process/test activity
> once it's been merged and generate a new ASLO activity index (not necessary
> at such an early stage.)
>
>
> Thanks,
> Jatin Dhankhar
>
> On Wed, Apr 5, 2017 at 3:17 PM, Tony Anderson <tony_anderson at usa.net>
> wrote:
>
>> Hi, Jatin
>>
>> Sorry, I was traveling and did not have access to the internet. I made
>> some comments below.
>>
>> One alternative format to ASLO is sugar-network (
>> <http://school-network.org/hub/?view=Catalog&workspace=activity&tab=toprated>
>> http://school-network.org/hub/?view=Catalog&workspace=activity&tab=toprated).
>> I see this as the top-level page (here all activities could be seen by
>> scrolling). I would see this page as allowing the user to input one or more
>> tags and see a page in the same format with just those activities with the
>> tag.
>>
>> A click on an activity would open the second-level (one activity per
>> page) with the full metadata and the download link.
>>
>> Your example has each activity occupying a large part of the screen, my
>> current implementation shows the activities about like an ls listing. Sugar
>> network is a compromise between.
>>
>> One part of the challenge is that we want an interface which is easy for
>> school children to use (generally with minimal English literacy). This is
>> the basis for an emphasis on icons. So rather than describing activities,
>> there should be an attractive background image that gives a clue as the the
>> nature of the activity. So, ideally descriptions should be localizable.
>>
>> If you want to get your feet wet, I can send you the current django code
>> and we could work together in adding capabilities - step by step. I am
>> reviewing the ASLO library to see which activities work with the current
>> release of Sugar (about two out of three so far). I hope to finish the
>> first pass tomorrow. So there are three strategies. One is to download the
>> download.sugarlabs.org repository (it should be open to anonymous ftp).
>> The second is to take only the current working activities (I am guessing
>> about 200-300 to start). But I would recommend a selection of 25 or so that
>> you can use to test the code. We can always add the rest as needed
>> (probably to set up an online site: activities3.sugarlabs.org. I
>> recommend this approach because we can put the project on Github/Sugar Labs
>> and can deploy the project on the same Sugar Labs server as ASLO (make
>> turnover easy).
>>
>> Tony
>>
>>
>> On 04/05/2017 02:41 PM, Jatin Dhankhar wrote:
>>
>> Hi,
>> Where should I start? Should I start working on the new ASLO ?
>>
>>
>> Thanks,
>> Jatin Dhankhar
>>
>> On Sun, Apr 2, 2017 at 4:28 PM, Jatin Dhankhar <
>> <dhankhar.jatin at gmail.com>dhankhar.jatin at gmail.com> wrote:
>>
>>> Hi Tony,
>>>
>>> Based on our suggestions I updated the proposal, thanks a lot for your
>>> inputs.
>>> <https://docs.google.com/document/d/1wECi_gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing>
>>> https://docs.google.com/document/d/1wECi_gtxyar3MWbC
>>> 8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing
>>>
>>>  the new version assume the master source repository is github and that
>>>> bundles are installed and updated via setup.py from github
>>>>             (the build and deployment methodologies). This means the
>>>> new system does not need to implement the Developer Hub.
>>>
>>> That seems a nice idea but won't there be need for moderation/approval
>>> of activities.
>>>
>>
>> This is handled by a Pull Request system. Essentially, there is a select
>> team that merges PRs into the git commits. So I anticipate that this team
>> would 'release' updated or new activities into the 'master' branch and then
>> deploy them to ASLO.
>>
>>
>>> Add recommendation engine - I think this is a distraction. How can a
>>>> program know the interests and needs of a user to provide a useful
>>>> recommendation? I also think the Review system is a distraction. The
>>>> problem is that no reviews come from actual users of the activities but are
>>>> similar to the sponsored reviews at Amazon. A better approach would be to
>>>> strengthen the tags/collections/category system.
>>>
>>> This can be useful if we want to show user, programs similar to what
>>> user already installed or suggestions based on what users installed along
>>> with following app but that is quite a work, we need to add analytics and
>>> stuff. Tags/collections/category is a simple way to achieve this nicely.
>>>
>>> Improve look/theme of ASLO - Naturally, this should be done in the
>>>> context of the project.
>>>
>>> Yes, I am looking at <http://beautifulopen.com>http://beautifulopen.com,
>>> for awesome examples.  I am liking these so far http://rouge.jneen.net/
>>>  and  <http://www.gnu.org/>http://www.gnu.org/software/guile/.
>>>
>>> I want to get started with discussion of potential design and tools for
>>> deploying activities.
>>>
>>> Thanks,
>>> Jatin Dhankhar
>>>
>>> On Sun, Apr 2, 2017 at 9:58 AM, Tony Anderson < <tony_anderson at usa.net>
>>> tony_anderson at usa.net> wrote:
>>>
>>>> Hi, Jatin
>>>>
>>>> The most important thing to keep in mind is that ASLO manages a library
>>>> of independent programs (Sugar activities). These are updated
>>>> asynchronously from the Sugar releases. Sugar is in desperate need of build
>>>> management - as best I can tell at the moment we have none. However, this
>>>> problem does not directly apply to the activities.
>>>>
>>>> The 'build' process for the activities is accomplished by 'python
>>>> setup.py dist_xo' executed in the bundle root. The generated xo file is
>>>> then 'deployed' to the appropriate directory in download.sugarlabs.org
>>>> as the latest version.
>>>>
>>>>
>>>> Since development time in GSOC is limited, it is critical to define a
>>>> doable project. In my experience proposals set unachievable expectations
>>>> and result in partially complete and disappointing results.
>>>>
>>>> Improve look/theme of ASLO - Naturally, this should be done in the
>>>> context of the project.
>>>>
>>>> Maintain ASLO - I am proposing that this project build a replacement
>>>> for ASLO which can be used immediately offline by school servers. During
>>>> the GSOC period, the community should be expected to judge whether the
>>>> development forms a base for future replacement of ASLO.
>>>>
>>>> Add recommendation engine - I think this is a distraction. How can a
>>>> program know the interests and needs of a user to provide a useful
>>>> recommendation? I also think the Review system is a distraction. The
>>>> problem is that no reviews come from actual users of the activities but are
>>>> similar to the sponsored reviews at Amazon. A better approach would be to
>>>> strengthen the tags/collections/category system.
>>>>
>>>> Improve Transactional emails - I think this is also a distraction. The
>>>> user communication is clicks on links. The response is public.
>>>> So I would propose something like:
>>>>
>>>>         - develop a new ASLO as activities3.sugarlabs.org based on
>>>> Django (to this end I can supply my current minimal working version).
>>>>
>>>>         - the new version assume the master source repository is github
>>>> and that bundles are installed and updated via setup.py from github
>>>>             (the build and deployment methodologies). This means the
>>>> new system does not need to implement the Developer Hub.
>>>>
>>>>         - the core activities (Journal, Record, Log, Terminal, Write,
>>>> Jukebox, Image Viewer, Browse, and Read) be excluded from ASLO and handled
>>>> through the                 Sugar release cycle). These activities are
>>>> installed in a Sugar release and the ability to erase them is disabled.
>>>>
>>>>         - for simplicity, the initial version could be limited to two
>>>> templates: an index page showing icons and names of activities and a page
>>>> per activity with the download button.
>>>>
>>>>         - There should be a simple and transparent 'CRUD' capability
>>>> for the metadata - perhaps in the first commit based on Django's admin
>>>> feature. I think the first commit db could consist of a single table: one
>>>> row per activity.
>>>>
>>>>         - Do whatever can be done to improve the attractiveness of the
>>>> site.
>>>>
>>>>         - Do not base development on emulation of any other project:
>>>> Mozilla add-ons or Play Store or .... Certainly the project can and should
>>>> be take inspiration                 from any source. However, it will be
>>>> enough to attempt to provide the essential current functionality of ASLO.
>>>>
>>>> What I visualize is the project be installed on github at the point of
>>>> a first working commit. The project could then be installed as
>>>> activities3.sugarlabs.org for community testing and advice.
>>>> Development would be using git locally using localhost or a local server.
>>>> Commits would be pushed to GitHub at appropriate points in the development
>>>> and the resulting version would then be used to update the online version.
>>>> The project would work with the current download.sugarlabs.org as the
>>>> source of bundles. (therefore, keeping the addition of activities to GitHub
>>>> as a separate project).
>>>>
>>>> Keep in mind, I am speaking for myself. While, if your project were
>>>> selected, I would probably be a mentor - this gives me no special voice in
>>>> the selection. Normally we have several proposals for each available slot
>>>> and many worthy proposals are not selected.
>>>>
>>>> Tony
>>>>
>>>>
>>>> On 04/01/2017 09:29 PM, Jatin Dhankhar wrote:
>>>>
>>>> Hi Tony,
>>>>
>>>> I think the same, as per commit history project didn't get much
>>>> attention recently.
>>>>
>>>> The website itself is implemented in PhP and is patterned after the
>>>>> Mozilla addons site.
>>>>
>>>>
>>>> Yes, the README mentions it's based upon Remora(http://wiki.mozilla.org
>>>> /Update:Remora ) which old and deprecated now in favor of AMO (
>>>> https://wiki.mozilla.org/AMO:Developers) .
>>>>
>>>>> At the moment I am trying to find out which of the activities actually
>>>>> work in the current release of Sugar. The library currently has about 600
>>>>> activities. A Sugar activity is intended to be self-contained (any
>>>>> dependencies not satisfied by Sugar are to be incorporated in the bundle).
>>>>
>>>> I think it's a moonshot but I am thinking to include a testing suite to
>>>> determine whether a current version builds against a certain sugar version
>>>> by using a CI or something like  OpenSuse's QA (http://open.qa/) for
>>>> more comprehensive suite.
>>>>
>>>>> How this will be done is a mystery to me. Logically, each of the
>>>>> versions of an activity should be commited in git so that a developer (or
>>>>> maintainer) can the changes made over time.
>>>>
>>>> Yes, that seems right thing to do, last year Arch Linux shifted all
>>>> their AUR packages to a git backend, maybe they can help, I can try finding
>>>> persons who carried out the transition.
>>>>
>>>>> If you look at the ASLO site, it seems clear that the page needs to
>>>>> specify more than which versions of Sugar are supported. It will need to
>>>>> specify which models of the XO are supported. It will also need to mention
>>>>> any restrictions on architecture or peripherals needed for the users system
>>>>> (microphone, camera, network connection - wired or wireless, and so on).
>>>>
>>>> Yes more like a Manifest, similar to what Play Stores does for Android.
>>>>
>>>>>  My plan is to use Django (which enables code to be in Python and not
>>>>> PhP). The school server already provides sqllite, mariadb, and postgresql
>>>>> so db support is readily available. Django is designed to support fusion -
>>>>> creating web pages dynamically based on information from a db and so should
>>>>> match the requirement.
>>>>
>>>> Yes, re-write seems a reasonable choice. One thing that I am curious is
>>>> that current repo suggests that it's is a mix of Python and PHP and going
>>>> full python would be a great move, in my opinion.
>>>>
>>>>> Just for further background. Many deployments I work with have no
>>>>> access to the internet. To provide an alternative, I support a school
>>>>> server which XO users can access by wifi in the classroom
>>>>
>>>> I think point makes a strong case for easily replicable instances of
>>>> ASLO with little to no configuration on the user side, which means we need
>>>> to make a simple and consistent build process so that users can run their
>>>> own versions of  ASLO easily. Docker is a option worth looking into.
>>>>
>>>>> I hope you will consider this challenging and not discouraging.
>>>>
>>>> Yes, I find it equally challenging and interesting.
>>>> I made a proposal ASLO that shares some of the concerns that you
>>>> discussed . Kindly take a look and let me know what do you think of it.
>>>> Here is the proposal link https://docs.google.com/d
>>>> ocument/d/1wECi_gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing
>>>> Thanks,
>>>> Jatin Dhankhar
>>>> On Sat, Apr 1, 2017 at 3:20 PM, Tony Anderson <tony_anderson at usa.net>
>>>> wrote:
>>>>>
>>>>> Hi, Jatin The ASLO site is in desparate need of work. At the moment I
>>>>> am trying to find out which of the activities actually work in the current
>>>>> release of Sugar. The library currently has about 600 activities. A Sugar
>>>>> activity is intended to be self-contained (any dependencies not satisfied
>>>>> by Sugar are to be incorporated in the bundle). Naturally, an activity
>>>>> should work on any Sugar. However, this situation is becoming very
>>>>> complicated. First, two of the XO models (1 and 1.5) have Intel 32 bit
>>>>> architecture processors. The others (1.75 and 4) have Arm processors. Some
>>>>> of the activities incorporate binary modules which limit their use. The
>>>>> Sugar community wishes to support Sugar on a range of platforms. For mobile
>>>>> devices, Lionel Laske is developing Sugarizer. While traditional activities
>>>>> were implemented in Python (with some binary exceptions using Java or C),
>>>>> Sugarizer activities are written in Javascript (HTML5 and CSS). Naturally a
>>>>> trend in modern computers is to 64 bit architecture (AMD 64). The website
>>>>> itself is implemented in PhP and is patterned after the Mozilla addons
>>>>> site. It has a repository of activity bundles (.xo files) which is visible
>>>>> at http://download.sugarlabs.org. Each activity has an 'add-on' id
>>>>> (4000-4999 at the moment). Versions of activities are numbered beginning
>>>>> with 1 and incrementing by 1 with subsequent versions. So the directories
>>>>> in ASLO contain bundles for multiple bundles with the highest numbered
>>>>> version considered the latest. In addition to the bundle, the site contains
>>>>> metadata which is displayed in the pages devoted to an activity. I suspect
>>>>> this metadata is stored in a database but I haven't investigated to find
>>>>> out the details. In the meantime, Sugar Labs has decided to create a
>>>>> repository for activities in github. The reasoning appears to be that this
>>>>> will make it easier for the community to undertake ongoing development and
>>>>> maintenance of these activities. Currently, the ASLO site has a 'developer
>>>>> hub' which allows registered users to add or update their own activities.
>>>>> This function will need defined and moved to github. How this will be done
>>>>> is a mystery to me. Logically, each of the versions of an activity should
>>>>> be commited in git so that a developer (or maintainer) can the changes made
>>>>> over time. Also, some method is needed to manage over 600 additional
>>>>> repositories in the Sugar Labs github. If you look at the ASLO site, it
>>>>> seems clear that the page needs to specify more than which versions of
>>>>> Sugar are supported. It will need to specify which models of the XO are
>>>>> supported. It will also need to mention any restrictions on architecture or
>>>>> peripherals needed for the users system (microphone, camera, network
>>>>> connection - wired or wireless, and so on). Over time, Sugar has dropped
>>>>> many packages which were ordinarily included. This has rendered many of the
>>>>> activities currently unusable. For example, Sugar switched from a browser
>>>>> based on hulahop to one based on WebKit. Some effort will be needed to
>>>>> update activities using hulahop to use WebKit. Sugar Labs hopes that
>>>>> activities will be ported to GTK3 (called sugar3) from the original GTK
>>>>> (sugar). If this can be accomplished, the size and complexity of Sugar can
>>>>> be significantly reduced. I hope you will consider this challenging and not
>>>>> discouraging. Just for further background. Many deployments I work with
>>>>> have no access to the internet. To provide an alternative, I support a
>>>>> school server which XO users can access by wifi in the classroom. My hope
>>>>> is to provide a version of ASLO on the school server which will give these
>>>>> users the ability to install any of the activities they choose and for
>>>>> which their XO has storage capacity. That capability exists now (and has
>>>>> for some years). However, the selection is basically a list of activities
>>>>> by name and does not provide the metadata descriptions found on the ASLO
>>>>> pages. My plan is to use Django (which enables code to be in Python and not
>>>>> PhP). The school server already provides sqllite, mariadb, and postgresql
>>>>> so db support is readily available. Django is designed to support fusion -
>>>>> creating web pages dynamically based on information from a db and so should
>>>>> match the requirement. Tony
>>>>> On 04/01/2017 04:00 PM, Jatin Dhankhar wrote:
>>>>>
>>>>> Hi Tony,
>>>>>
>>>>>> There are two major elements to Sugar. The desktop interface - Sugar
>>>>>> and the activities. ASLO is a library of these activities. Build only
>>>>>> applies to Sugar.  For a non-XO version of Sugar, there are two easy
>>>>>> choices: SOAS and Sugar on Ubuntu. For Ubuntu, install 14.04 or more recent
>>>>>> version (I am using 16.04) and execute sudo apt-get install sucrose. For
>>>>>> SOAS, download the image and dd it to a usb stick. It works as a livecd.
>>>>>
>>>>> Thank you for all the information :)
>>>>>
>>>>>> Make Your Own Sugar Activities!
>>>>>> By James Simmons
>>>>>> <http://www.lulu.com/shop/search.ep?contributorId=739770>
>>>>>>
>>>>>> Make sure to get the second edition.
>>>>>>
>>>>> Specially the book, it's very detailed and comprehensive.
>>>>>
>>>>>> Another alternative is to build the 'development environment'. This
>>>>>> environment is intended for developers who are working directly on PRs for
>>>>>> Sugar modules.
>>>>>
>>>>> Yes, I am looking to build the 'development environment', specially
>>>>> the ASLO server but I am facing some issues. since sphinx is very old and
>>>>> cannot be compiled (using make) properly. Wanted to know if there is
>>>>> someone who maintains the ASLO and  can answer this specific query, related
>>>>> to building ASLO locally and getting started on it
>>>>> Thanks,
>>>>> Jatin Dhankhar
>>>>> On Sat, Apr 1, 2017 at 6:31 AM, Tony Anderson <tony_anderson at usa.net>
>>>>> wrote:
>>>>>>
>>>>>> Hi Jatin, There are two major elements to Sugar. The desktop
>>>>>> interface - Sugar and the activities. ASLO is a library of these
>>>>>> activities. Build only applies to Sugar. For a non-XO version of Sugar,
>>>>>> there are two easy choices: SOAS and Sugar on Ubuntu. For Ubuntu, install
>>>>>> 14.04 or more recent version (I am using 16.04) and execute sudo apt-get
>>>>>> install sucrose. For SOAS, download the image and dd it to a usb stick. It
>>>>>> works as a livecd. Another alternative is to build the 'development
>>>>>> environment'. This environment is intended for developers who are working
>>>>>> directly on PRs for Sugar modules. In deploying Sugar, the only fully
>>>>>> supported platform is the XO. The Ubuntu Sugar appears not to connect to
>>>>>> networks and omits some of the essential activities. These are the
>>>>>> essential eight: Browse, Record, Jukebox, Terminal, Log, Write, Read, and
>>>>>> Image Viewer. Several of these such as Record provide access to hardware
>>>>>> features of the platform such as the camera and microphone. Naturally,
>>>>>> these are more difficult to support on general platforms. There are two
>>>>>> programming environments for Sugar activities: Python and Javascript.
>>>>>> HelloWorld and HelloWeb are simple examples of activities in Python and
>>>>>> Javascript, respectively. There is an excellent text available for download
>>>>>> online:
>>>>>> Make Your Own Sugar Activities!
>>>>>> By James Simmons
>>>>>> <http://www.lulu.com/shop/search.ep?contributorId=739770>
>>>>>>
>>>>>> Make sure to get the second edition.
>>>>>> Tony
>>>>>> On 04/01/2017 12:00 AM, aslo-request at lists.sugarlabs.org wrote:
>>>>>>
>>>>>> Send ASLO mailing list submissions to
>>>>>> 	aslo at lists.sugarlabs.org
>>>>>>
>>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>>> 	http://lists.sugarlabs.org/listinfo/aslo
>>>>>> or, via email, send a message with subject or body 'help' to
>>>>>> 	aslo-request at lists.sugarlabs.org
>>>>>>
>>>>>> You can reach the person managing the list at
>>>>>> 	aslo-owner at lists.sugarlabs.org
>>>>>>
>>>>>> When replying, please edit your Subject line so it is more specific
>>>>>> than "Re: Contents of ASLO digest..."
>>>>>>
>>>>>>
>>>>>> Today's Topics:
>>>>>>
>>>>>>    1. ASLO build and deployment process (Jatin Dhankhar)
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> Message: 1
>>>>>> Date: Fri, 31 Mar 2017 16:57:58 +0530
>>>>>> From: Jatin Dhankhar <dhankhar.jatin at gmail.com> <dhankhar.jatin at gmail.com>
>>>>>> To: aslo at lists.sugarlabs.org
>>>>>> Subject: [ASLO] ASLO build and deployment process
>>>>>> Message-ID:
>>>>>> 	<CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com> <CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com>
>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have few questions about how ASLO is actually build and deployed in
>>>>>> production. Build process is carried out by using Fabfile, I tried using
>>>>>>  it and was not successful in building the sphinx ( since version used is
>>>>>> 0.9.9.rc2 and current series is 2.x).
>>>>>> Relevant pull request and issue
>>>>>> PR -> https://github.com/sugarlabs/aslo/pull/2
>>>>>> Issue -> https://github.com/sugarlabs/aslo/issues/1
>>>>>>
>>>>>> I am using Arch Linux and have installed all the necessary dependencies for
>>>>>> development including mysql and postgres development libraries along with
>>>>>> common development libraries. If anyone can point on how to successfully
>>>>>> build the project that would help a lot.
>>>>>> Some thread points out upgrading to new version of Sphinx but I wanted to
>>>>>> mirror the current instance.
>>>>>> Also project mentions something about Remorahttps://wiki.mozilla.org/Update:Remora and wiki says it's no longer
>>>>>> maintained.
>>>>>> It quotes
>>>>>>
>>>>>>
>>>>>> Remora is no longer maintained. See AMO:Developers<https://wiki.mozilla.org/AMO:Developers> <https://wiki.mozilla.org/AMO:Developers>.
>>>>>>
>>>>>> Also wanted to know more about how ASLO is deployed in production. What
>>>>>> techniques are used ? What are the pain points that need to be addressed
>>>>>> and tips on how to get started with it. If anyone is familiar with ASLO or
>>>>>> a long time maintainer, can they point out on how to reproduce a successful
>>>>>> build of ASLO (a documentation on how to run would be awesome)
>>>>>>
>>>>>> Thanks,
>>>>>> Jatin Dhankhar
>>>>>> -------------- next part --------------
>>>>>> An HTML attachment was scrubbed...
>>>>>> URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170331/12204ccc/attachment-0001.html> <http://lists.sugarlabs.org/archive/aslo/attachments/20170331/12204ccc/attachment-0001.html>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Subject: Digest Footer
>>>>>>
>>>>>> _______________________________________________
>>>>>> ASLO mailing listASLO at lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/aslo
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> End of ASLO Digest, Vol 84, Issue 1
>>>>>> ***********************************
>>>>>>
>>>>>> _______________________________________________ ASLO mailing list
>>>>>> ASLO at lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/aslo
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170406/d410b6f2/attachment-0001.html>
Previous message (by thread): [ASLO] ASLO build and deployment process (Jatin Dhankhar)
Next message (by thread): [ASLO] ASLO build and deployment process (Jatin Dhankhar)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the ASLO mailing list