[ASLO] ASLO build and deployment process (Jatin Dhankhar)
Tony Anderson
tony_anderson at usa.net
Wed Apr 5 21:41:38 EDT 2017
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 <http://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
> <mailto: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 <http://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
> <http://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 <mailto: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_gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/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, for awesome
>> examples. I am liking these so far
>> http://rouge.jneen.net/ and 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 <mailto: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
>> <http://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
>> <http://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
>> <http://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 <http://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
>>> <http://wiki.mozilla.org/Update:Remora> ) which old and
>>> deprecated now in favor of AMO
>>> (https://wiki.mozilla.org/AMO:Developers
>>> <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/document/d/1wECi_gtxyar3MWbC8ly6bjdW8SSLYe5YNcXPiTUUlkg/edit?usp=sharing
>>> <https://docs.google.com/document/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 <mailto: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
>>>> <mailto: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.o
>>>> <mailto:aslo-request at lists.sugarlabs.o>rg wrote:
>>>>> Send ASLO mailing list submissions to
>>>>> aslo at lists.sugarlabs.org
>>>>> <mailto:aslo at lists.sugarlabs.org>
>>>>>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>> http://lists.sugarlabs.org/listinfo/aslo
>>>>> <http://lists.sugarlabs.org/listinfo/aslo>
>>>>> or, via email, send a message with subject or body 'help' to
>>>>> aslo-request at lists.sugarlabs.org
>>>>> <mailto:aslo-request at lists.sugarlabs.org>
>>>>>
>>>>> You can reach the person managing the list at
>>>>> aslo-owner at lists.sugarlabs.org
>>>>> <mailto: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>
>>>>> <mailto:dhankhar.jatin at gmail.com>
>>>>> To:aslo at lists.sugarlabs.org
>>>>> <mailto:aslo at lists.sugarlabs.org>
>>>>> Subject: [ASLO] ASLO build and deployment process
>>>>> Message-ID:
>>>>> <CAD+LdAF26TWi9uPP0pPZPTFWm3L5HF3=ubc4_TBY9O8v_e=T1Q at mail.gmail.com>
>>>>> <mailto: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
>>>>> <https://github.com/sugarlabs/aslo/pull/2>
>>>>> Issue ->https://github.com/sugarlabs/aslo/issues/1
>>>>> <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 Remora
>>>>> https://wiki.mozilla.org/Update:Remora
>>>>> <https://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 list
>>>>> ASLO at lists.sugarlabs.org
>>>>> <mailto:ASLO at lists.sugarlabs.org>
>>>>> http://lists.sugarlabs.org/listinfo/aslo
>>>>> <http://lists.sugarlabs.org/listinfo/aslo>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> End of ASLO Digest, Vol 84, Issue 1
>>>>> ***********************************
>>>> _______________________________________________
>>>> ASLO mailing list ASLO at lists.sugarlabs.org
>>>> <mailto:ASLO at lists.sugarlabs.org>
>>>> http://lists.sugarlabs.org/listinfo/aslo
>>>> <http://lists.sugarlabs.org/listinfo/aslo>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/aslo/attachments/20170406/6eb3aaed/attachment-0001.html>
More information about the ASLO
mailing list