GSoC 2014, Week #13: All good things must come to an end

Hello everyone,

    As you might already know, this is the last post for my Google Summer of Code endeavour for this year. That said, that doesn't mean that this last week was spent doing nothing.

1.) Pull Requests, merged:

    All my previous pull requests for features that I wanted to add to layman have been merged with master. This includes the overlay-maker utility, squashfs-support, the portage sync plug-in, the ability to disable and enable a repository, modular overlay types, and more!

2.) Goodbye G-Common:

    G-common was an overlay type that was supported by Gentoo. It was decided that g-common was no longer going to be supported because no one (that we can tell) uses it. Typically you wouldn't see this type of thing happening, but g-common was replaced by g-sorcery. Which is the latest variant of that tool.

    I personally have no experience with either VCS, but I have spoken to the maintainer of g-sorcery.

3.) Modular Configuration types:

    Remember the RepoConfManager class? The class that handles all the repo configuration configuring has now been modified to support config type modules. So what does that mean? It means if a user has a configuration method that they want to support for layman they only need to add the module to layman's codebase and add the option to their layman.cfg.

    The same can be said for layman overlay types. If a user would like layman to support an overlay type that's not currently supported then all they need to do is add the module. If it works well, you could then submit a bug report and submit a patch with the new module and it might be added to layman on the next release.

4.) Documentation changes:

    With new features comes new documentation. This should always be the case, always. So users can be aware of the latest and greatest things that have been done to their newest release. In preparation for a new release, the man pages have been modified, the layman,cfg has been modified, and the version has been bumped to 2.2.0!

5.) Code refining:

    As I had said previously, you will never stop refining your code. I will bug squash till the day I die and I'll love every second of it too. After the documentation changes were made, the live ebuild (9999) for layman was updated as well. So users could now install (and test) the latest codebase for layman and return feedback to me to allow me to improve upon my code, or fix mistakes previously missed. A few bugs here and there have been found and squashed throughout the span of this week.

Goals for next week:

• Go to School, get my education on.
• Enjoy this last week of Summer.

    I would like to say thank you to everyone who assisted me throughout the span of this program and I thoroughly enjoyed myself working on layman, in an effort to contribute to the Gentoo community. As I said above, the layman-9999 ebuild is available for people to test, and I welcome all feedback!

With regards,
    Devan Franchini (twitch153)

GSoC 2014, Week #12: Starting to wrap everything

Hello faithful readers!

    As the title says, things are beginning to get wrapped up nicely with a little bow and everything.

    A lot of time this week was spent on trying to get all my pull requests pushed to layman's master branch. Two notable ones (in my opinion) that got merged into the master branch were the overlay-maker tool and the portage sync plug-in. However, a few things needed to be changed to get these features up to snuff, particularly the overlay-maker.

1.) Overlay maker auto-completion improvements:

    Recall previously that I discussed that the overlay-maker has auto-completion for source URLs? Well the code for that was admittedly very horrid to go through. Not very clean, not very easily maintained.

    In order to improve upon that, I took the original concept and changed the implementation almost completely.

    Originally, if you were to give the overlay-maker the source URL of "git://git.overlays.gentoo.org/proj/layman.git" a series of string modifications were made to turn that source into two other source URLs along with the homepage and two separate feeds.

    To do this, there was a function called _set_gentoo_info() or something very similar to that. Sounds a little complex, but not really. Right? Right. I would agree with you. But imagine if you wanted to add support for another source URL for auto-completion of information? And then another? If we go under the assumption that the _set_gentoo_info() function was roughly 45-50 lines of code and we wanted to add two more source URLs for support then that's an additional 45-50 lines of code per source mirror!

    That's what we call "spaghettified code" and it's not pretty, and not always necessary.

    So for the sake of space, maintainability, and pride in your ability to code you want to take something like that down from 135-150 lines to 60 lines of code. Maintain the idea of modifying the URLs and feeds, and the homepage based on a specific URL mirror such as github, gentoo, or bitbucket. Then realize what differs from one github URL to another github URL. Those are your variables.

    After that it's as simple as creating a template constant that includes the auto-completion information for you. Once that's implemented then it's as simple as breaking up the URL into the variables you need and then perform interpolation on the template to get the correct overlay information.

   To anyone interested in seeing that concept in action then you should take a peak at: https://github.com/twitch153/layman/commit/7537f0b6216c2cbb13e2059edd9be0ed8e19a097

2.) Overlay-maker CLI interface:

    Up until now whenever a user wanted to tell the overlay-maker that they wanted to have auto-completion support for their overlay then they had to specify on every overlay creation. That can get tedious and sometimes annoying if you're working on adding a large amount of overlays to an xml. In favor of ease of use and not wanting users to curse my name at the end of their keyboard I gave users the ability to simply specify this via command line arguments.

    You can now do the following:

• List all mirrors supported for auto-completion.
• Tell the overlay-maker you only want the bare basics for the overlay(s) you are creating.
• Select a mirror for auto-completion when creating your overlay.
• Override certain checks when creating an overlay such as only saving the overlay.xml in your "overlay_defs"  location and giving an overlay a name of an overlay that already exists.

After both these changes were made to the overlay-maker then it was time that the pull-request was merged into master. It's only a matter of time before a new release is available to users (wink, wink).

3.) Merged test-suite and updated-updater:

    Both of these branches were merged to master along with the other two.

    The changes made to the test-suite were simple things like modifying what gets checked to assure that the test is working out exactly as it should.

     The changes made to updated-updater were also minimal. Now updater.py will check to see which conf_types are enabled and will then create the proper configuration files based on that.

    This brought the pull-request count down from 7 to 3! Which just shows how much closer we are to completion.

4.) Added layman-mounter tool:

    Recall in the past (we seem to do that a lot recently) that I added squashfs overlay support to layman. Well, it turns out that the method I used to add the support by unpacking the archive wasn't what my mentor had in mind (whoops!). After a little bit of discussion we came to the agreement that we wanted to add squashfs support to layman so that it would mount it read-only.

    The benefit of this is that you save space on your system. The drawback is that once you reboot your computer the overlay is no longer mounted.

   To address that drawback a utility script was created called "layman-mounter". This sounds a little...odd for a tool. What will this do? Well, it's not that odd. Really. I swear. And it does the following:

1. lists all mountable overlays.
2. lists the status of all mountable overlays (mounted/unmounted).
3. Can mount overlay(s).
4. Can unmount overlay(s).

    The beauty of that is that a user can then have layman-mounter invoked on every reboot to mount all your overlays. Or only select ones. The squashfs overlay code was also changed to reflect the behavior of being mounted instead of extracted. So look for this handy tool on the next release.

    Be aware that this method of squashfs overlay support does require you to have CONFIG_SQUASHFS enabled in your kernel though.

Goals for next week:

•  Work on getting the last three pull-requests merged with layman's master branch.
• Add modular configuration plug-ins.
• Refine any code necessary in order to get a new release out before the end of the program.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)

GSoC 2014, Week #11: Code Refinement at its finest

Hello again everyone,

This week was a fairly busy week due to my birthday and all the celebration that revolved around that.

Don't worry though! I didn't completely slack off. Work was accomplished.

1.) Modular overlay type plug-ins:

    If you can recall from my previous posts, I explained a little about the SquashFS overlay type as well as making the code for both Tar and SquashFS overlay types common in one class called ArchiveOverlay. If any of that doesn't sound familiar, no worries. I'll explain as we go along. But knowing of that will help you understand a bit better of what I'm about to discuss.

    This week I implemented a system in layman that will interact with modules. This commit: https://github.com/twitch153/layman/commit/0d4523513464c9bce836308d085995cb8a24644b is the module plug-in system and essentially what it does is look in a specified directory and find all available plug-ins. From there it will become a container of sorts that will obtain the class of any module, by name.

    This logic was then implemented into layman's overlay types. Recall wanting to install the overlay "twitch153". You would invoke layman as so: layman -a twitch153 and it would install (as long as you have git installed on your system). So you need to have git on your system and layman just magically takes care of it! Vioala!

    Well, in reality, you need git on your system because layman is informed that the type of the overlay is "git". The Overlay class will then find the proper class associated with "git", which in turn would be "GitOverlay". From there it would go to that class' add() function to see what steps would be necessary to add the overlay.

    As always, we strive to know more about why things happen. So why oh why am I explaining this to you and wasting the precious time you could be spending looking at lolcats and looking at other people's pictures of their food on their Facebook? Simple. Now that the module plug-in system has been implemented the Overlay class no longer needs to keep track of the available overlay type classes. This makes the main code much more maintainable, as well as making the addition of a new overlay type (such as squashfs) as simple as adding it to the correct directory and configuring it correctly.

    This also has another benefit to it. If this gets implemented into the main version of layman (which I would hope it does), it would make it possible to split out the modules into their own separate packages. This follows the Gentoo mentality of having choice. In previous versions of layman (even the current 2.1.0), you have specific USE flags that determine which VCSs you would add support for in layman. So if you were to install layman with USE='-darcs' you would not emerge the darcs version control system as a dependency. You would, however still have the code in layman that handles darcs overlays.

    This goes against the mentality of choice and forces users to have something on their system that they might never use. This is why the nature of modular overlay-type plug-ins is a great thing.

That's all that was accomplished this week. I do hope to work a little more next week to try to pick up some of the slack I left behind because of my birthday. But hey, if you can't celebrate your own birthday then I feel bad for you.

Goals for next week:

•  Work on anything I need to in order to get the overlay-maker and the sync-plugin into the master branch of layman.
• Discuss splitting the layman overlay-type plug-ins.
• Refine layman's codebase.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)

GSoC 2014, Week #10: Testing, Testing, 4, 5, 6...

Welcome back to all my long term readers, and to anyone new...welcome! Hope you enjoy this blog as much as I enjoy writing for it.

Unbeknown to me previously, my mentor had surgery while he was in the hospital. I was actually quite shocked to hear that, considering his condition previously. I just wanted to take the time here to say that I hope he has a good, and painless recovery. In the very least, I hope he is able to fully recover.

This week, the following has been accomplished:

1.) More docstring migrations to test suite:

   If you've been keeping up with my posts you'll know that this week is the second week that I've been working on migrating from docstring tests in layman's code, to a full test suite.

   Good news is, this is my second week and I should be wrapping it up at a good number of 13 tests.

   Although this means little to your average user, the tests are a necessary part of assuring that the code works precisely as it says it does.

   The keyword of the day is quality assurance, or simply put: QA. QA is HUGE in the Gentoo Developer community. It's like the law of the land, metaphorically speaking. As I am part of the amazing Gentoo developer community I too firmly believe in QA and its necessity in our code. That doesn't mean I don't believe people make mistakes though. That's why these tests exist, to confirm that everything is working as it should.

2.) New layman release:

   To those of you who have been waiting for an official version of layman to be released that includes all the amazing work that has been done up until...roughly my fifth week or so working on it, well wait no more! layman is now officially at version 2.1.0 (OoooOOoooh AaaAaaAAaah).

   A handful of things had to be done previously to allow this release to be done, including uploading the source to sourceforge.com, as well as updating the CHANGES file to allow users to see what has been changed since the last release. Nothing spectacular or amazing, but still a very necessary part of the development cycle.

   It's almost neglectful to just push out a new version of something without telling people what's new about it. Although, this is just my own opinion on that.

   So fire up your CPU and get to installing layman-2.1.0, and be sure to give me some proper feedback on things I've done to make your life easier/harder. Especially if I made it harder due to some unforeseen bug in my code.

   I apologize about the short post, fingers crossed that next week I can give the post just a little bit more substance.

Goals for next week:

• Begin making layman VCS types modular.
• Polish any code already in layman's codebase.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)

GSoC 2014, Week #9: Testing, testing, 1, 2, 3...

Hello everyone!

Good news! My mentor, Brian Dolbec (aka, dol-sen) has returned from the hospital! He has to take things slow but at least we know he made it out alive. Best wishes for him and I hope everything goes well for him.

In an attempt to make things as short as possible here is what has been accomplished this week:

1.) Improvements to overlay-maker class:

1. Support for bitbucket.org mirror auto-fill info has been added. When a user now gives the overlay-maker class a bitbucket.org source URL it will now try to determine which VCS type it is, as well as the possible feed and homepage URLs.
2. In addition to adding the support for bitbucket.org auto-fill info, the function necessary to auto-fill the info for source URLs has been cleaned up for improved maintainability.
3. The get_input() and get_ans() functions were improved upon, to allow for a colorful interface with users, similar to the output messages of layman. This was done for overlay uniformity and to just be...pretty.
4. Message output for the overlay-maker class has been migrated from your run-of-the-mill print() functions to the output suite that layman has readily available. Again, this brings a uniform look to the interactive sessions.
5. The get_ans() and get_input() functions were moved to utils.py. This allows them to be where they should belong, as well as making them readily available to other classes that can make use of them (ex: db.py).

2.) Added disable and enable functionality to repos.conf files:

    Do you all remember in my last post where I mentioned the ability to disable and enable a repository in the make.conf files? Well, I discussed it over with dol-sen and we figured the best way to "disable" a repo for repos.conf files is to simply comment it out.

    Because that is the case, adding support was easy and is now readily available to be merged onto the master git branch,

3.) Began migration from doctests to test suite:

    Essentially a doctest is an in ".py" file test that was run via the python command line. It it a test that can be run to ensure that the function that is being tested, actually works. The drawback of doctests (in my humble opinion) is that they should belong in a separate place aside from the actual ".py" file that is being tested.

    If we're moving the tests to a separate place, why not just move them from doctests to the actual implementation of the test?

    That's what I aim to accomplish in this upcoming week (and what I've been working on this week).

    To see a full list of tests added to the test suite, look at the test-suite branch on my layman github repo.

 Goals for next week:

•  Continue working on migrating docstring tests to a full test suite.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)

GSoC 2014, Week #8: Squashing some bugs

Hello everyone!

This week has been good in making leeway with open bugs for layman!

To all of you who are unaware of what bugs are (no, not the squirmy wormy ones), a bug is essentially a report regarding a certain program or package or pretty much whatever. It can cover a vast amount of things.

If you are curious to see the open bug for layman, follow this link here:
https://bugs.gentoo.org/buglist.cgi?quicksearch=layman&list_id=2406998

But I'm getting ahead of myself, I'm going to begin by discussing what has been accomplished this week for layman.

1.) Centralize archive overlay type code:

    Last week I added support for squashfs overlay types for layman and it struck me: "Hrm, the code for both tar overlays and squashfs overlays are super similar. So similar, in fact that the differences are less than the similarities. I bet I could make a class that all archive types get their main functions from". So that's exactly what I did!

    I created the ArchiveOverlay class which took all the similar code from both archive overlay types and brought it together for any archive overlay type to grab from. It's like a goody bag of archive functions.

   So now any archive overlay type will now subclass from the ArchiveOverlay instead of the SourceOverlay class, which the ArchiveOverlay class subclasses from. It's a large hierarchy that is as follows:

                             <archive overlay type being installed>
                                                           |
                                                     Overlay
                                                           |
                                          <archive overlay type>
                                                           |
                                                ArchiveOverlay
                                                           |
                                                 SourceOverlay
                                                           |
                                              Overlay installed
                                                           |
                                                         ???
                                                           |
                                                       Profit!

    When you go to install a tar overlay layman will know it is a tar overlay type. The Overlay class will then call the class associated with that type, being tar. The class associate with tar is...TarOverlay! So the TarOverlay class is called, and it wants to call the add() function. However, if you looked at the source code you'd see that the TarOverlay class doesn't have an add() function. So where does it get it from? The ArchiveOverlay class that it subclasses.

   The ArchiveOverlay class requires you to extract the archive, that the TarOverlay class has in its own class, that's what makes this class different from say...the SquashfsOverlay class. The way you extract the archive is different.

   So the TarOverlay class will call the ArchiveOverlay class' add() function which in turn will make use of the TarOverlay class' extract() function. The ArchiveOverlay class' add() function isn't complete though, it will make use of the add() function in the SourceOverlay class, to do anything else that the ArchiveOverlay class' function didn't cover. After this is complete you can enjoy your newly installed archive overlay and feel happy that you didn't have to do anything more than: layman -a <overlay>

2.) Adding multiple description field support:

    If you look at this bug report here: https://bugs.gentoo.org/show_bug.cgi?id=465730 you will see that layman currently did not handle multiple description fields when there was the possibility to do so (mostly due to it being translated into different languages and whatnot). This week I added that support to the Overlay class.

    I personally believe it needs to be fine-tuned in a few ways. I think I will wait until dol-sen's recovery to fully tackle this bug though. In all honesty it would work fine now as it is, but would not take into account that lang attribute of the description xml tag.

    In accordance with the changes being made to the Overlay class to support multiple description fields, the layman sync plugin and the overlay-maker class both also have been modified to reflect the newly added support. The overlay-maker class does not currently add more than one description to the overlay being created though. A function has been added to grab the description though and can be used to prompt the user for multiple description fields if we decide that would best.

3.) Slight additions to overlay-maker class:

    A few changes have been made to the overlay-maker class.

1. github,com and git.overlays.gentoo.org https:// URLs are now supported (why they weren't before, I have no idea...I blame the media).
2. On a successful write, the user is now notified of where the xml file is being written to.

    Nothing massively crazy or huge, but helpful nonetheless.  I have hopes that the layman sync plugin module and the overlay-maker class will both be merged to layman's master branch soon. But no promises.

4.) Adds interactive session for unofficial overlay installs:

     https://bugs.gentoo.org/show_bug.cgi?id=315359 hoped to add more of a warning to users that are not installing official overlays. I added that feature which I also made configurable. So now a user will be prompted when installing unofficial layman overlays. They will be asked if they would like to continue even though the overlay is unofficial and if they respond with "yes" then they will continue on with the installation.

    This feature, as I said previously, will be configurable and will be able to be turned on or off with the "check_official" configuration option. The config option name might be changed in the near future and if it does you guys will be the first to know. Well, unless someone checks the source code and it's on there before I report it to you.

5.) CLI improvements:

    CLI or (command-line interface) is the method of calling a command through the command-line and give it certain command line arguments. You've seen this in layman -a <overlay> the command line arguments here are the -a flag and the <overlay> name.

    Keeping that in mind, know that if you previously wanted to install multiple layman overlays, you'd have to do it as so: layman -a <overlay 1> -a <overlay 2>. But to be honest that's not really a natural way of doing so. Over this week I changed the way layman handled certain actions such as --add or --delete. So now instead of having to call the flag multiple times you can simply append multiple overlay names to the actions, as so: layman -a <overlay 1> <overlay 2>.

    This was done by removing the action parameter of the argparser add_argument function, and replacing it with nargs = '+'. Doing this changes the behaviour of how the flag gathers its information and will allow users to perform layman actions in a more natural manner.

    Another minimal change has been made to the command line arguments as well. I have taken the liberty of renaming the --setup_help flag to --setup-help as it should have been originally. Whether I made this mistake or not, I'm not aware. But it's fixed now, which is good.

6.) Ability to enable or disable overlays:

    Imagine you're spending the night in a hotel that just so happens to have really crappy internet (it's not like they don't have multiple people using the internet all the time, all day long or anything...) and you want to prevent portage from accessing the ebuilds that a certain overlay has installed.

    So how would you tackle this problem? You could go ahead and delete the overlay. That would work, sure. Unfortunately, you'd have to download the overlay again after that's done. Which, given your current situation, would suck. Or you could just have portage "forget" the overlay exists.

    How? With layman's new ability to disable and then enable the overlay. Preface: this currently only works if you use the make.conf repo configuration method.

    If you were to look in your make.conf (located by default) in /var/lib/layman, you would see the following:

                                          PORTDIR_OVERLAY="

                                          <overlay locations>

                                          $PORTDIR_OVERLAY

                                          "

    With the ability to enable or disable an overlay, this had to be changed. It's a rather simple and elegant solution:

                                          ENABLED="

                                          <overlay 1 location>

                                          <overlay 2 location>

                                          "

                                          DISABLED="

                                          "

                                          PORTDIR_OVERLAY="

                                          $ENABLED

                                          $PORTDIR_OVERLAY

                                          "

    So now, portage will only acknowledge the overlays listed in the ENABLED var and ignore the overlays in the DISABLED var. When calling layman -D <overlay 1> the overlay location of <overlay 1> will then be moved to the DISABLED var in the make.conf. Which you can re-enabled by invoking the layman -E <overlay 1> command. I hope to incorporate this into the repos.conf repo configuration method as well but how layman should go about doing so needs to be discussed.

7.) Small fixes made to codebase:

    Two small fixes were made to layman's codebase.

1. Improvements of the way layman handled the success or failure of a write to a repo config method has been fixed. layman will now take into account the fact that a user can be invoking more than one repo config method and one may fail while the other succeeds. Previously this would lead to a false positive. That behaviour has been fixed.
2. layman previously falsely informed a user that an overlay was not supported if they ran layman -v -i <overlay> and the overlay was actually supported. This was because layman was unpacking the values from the Info() function and unpacked the boolean for "supported" in the position of the boolean for "official".

 Goals for next week:

•  Begin working on migrating docstring tests to a full test suite.
• This goal has been allotted to take 2 weeks so don't expect a massively fulfilling report next week. 

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)

GSoC 2014, Week #7: Going at a fine pace

Hello everyone!

This week has gone pretty well. I took yesterday off to spend the 4th of July with my family and I had some good times, but now is the time that I inform all you lovely readers what was accomplished throughout this week regarding layman.

A word beforehand, my mentor Brian Dolbec (dol-sen) is currently in the hospital and will be there at least until July 13th. I just wanted him to know that my best wishes go out to him and I hope the best for him.

While dol-sen is in the hospital recovering I will be bugging my other mentor (quantumsummers) a lot more than I bet he would hope for because I need the green light on my pull requests I have for certain features that I'll be elaborating more on in this post.

1.) Portage sync module plugin:

    The portage sync module plugin for layman should be ready to be merged with the master git branch. I required more seasoned eyes to skim through it and let me know that it is before merging it. The only change made to it throughout this week was that I added fetching of the remote list to layman by default when running any of the actions in the sync module.

2.) Overlay-maker class:

    This week has included a two changes for the overlay-maker class, one of which was made that directly affect the user.

    1.) The old method of branch tags has been removed:
            I previously added branch support for multiple overlay types.
    In order to declare an overlay had a branch you would simply add the
    <branch></branch> tags to indicate that the overlay uses this "branch".
    This has been changed. When you are creating an overlay.xml file now you
    can specify the branch for multiple source tags. ex.) You have an overlay
    located at http://github.com/twitch153/ebuilds.git and it uses the branch
    experimental, but you have another source of the same repo at
    git://foobar.com/twitch153/repo.git and it uses the branch unofficial. With
    the previous nature of the <branch></branch> xml tag you couldn't
    specify both tags for both sources and you'd be left sad and full of hate
    and anger toward the dev that made the decision to make it such a static
    thing. With the new nature of the branch info though you could do this:

        <source type="git" branch="experimental">http://github.com/twitch153/ebuilds.git</source>
        <source type="git" branch="unofficial">git://foobar.com/twitch153/repo.git</source>

     and that would work perfectly well! Of course, with this new change comes the need to modify the .dtd file again, so I'll have to create a patch and run that by the maintainers of the .dtd file once again. That'll be done once these changes get merged to the master branch.

    2.) Proper feed support was added for the overlay-maker class and
    overlay dictionaries:
        If a user was to run through an interactive overlay maker session and
    specified the feeds to the overlay and wrote the overlay to the file...it
    wouldn't work! Why? Well, it's simple really. The overlay-maker class is an
    interactive session that will create a python dictionary of overlay
    elements. However, due to my clear lack of perfection I used an incorrect
    key for the overlay feeds and therefore the overlay class would totally
    overlook the feeds when creating an overlay object to be written to an
    xml.

3.) Squashfs overlay support:

   For those of you unaware of what squashfs is: it is an archive-like file system. There are absolutely tons of different things about it that I could list but I lack the proper knowledge to continue on by saying anything other than it is like an archiving type similar to tar or zip.  So, in our vast abundance of knowledge we already know that layman already supports tar overlays so is squashfs really all that different? The answer is an emphatic no. It is my own belief that you could probably go even further and say that adding any sort of archive overlay support to layman would be so similar that you might want to make an archive class where all archive overlay types would get their main functions from and go from there based on the little differences that they do have.

    However, this week I added both squashfs overlay support and an external test to see if it works in practice and not just on paper (hint: it does).

Goals for next week:

• Improve on the archive overlay types and possibly make an archive class to centralize the main functions necessary for each type.
• Discuss with quantumsummers about moving some of my work to the master branch.
• Focus on squashing some bugs for layman.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)