Guidelines for extension submission

[Jason W]

Hi everyone,
The purpose of this post is to outline in some more detail the official procedure for submitting extensions.  The wiki contains some important information on how extensions should be built:

 http://wiki.tinycorelinux.net/wiki:creating_extensions
 
I won't recover all those steps here, but is important that extensions be built in accordance with those instructions to ensure that the extension will work well for other users and support our modes of operation. 

The official channel for extension submission is the tcesubmit _at_ gmail _dot_ com email account.  If you do not have access to gmail or the extension is over the size limit allowed by gmail, send an email to tcesubmit and explain that your submission cannot be emailed due to size and another means will be found.  Once an extension has been submitted, please monitor the email account that was used for sending the extension in case there are any questions I may have about the extension.  I am the team member who will be handling all submissions, and any questions you may have regarding your submission should be sent to the tcesubmit account until the extension is posted and an announcement is made.  But if you see me on IRC or in the forum you can ask me about your submission there as well.

I check the tcesubmit account daily and I aim for a maximum of 24-48 hours turnaround time between extension submissions and a response.  In the event I am away for more than that I will summon help from other team members so extensions should always be processed in a timely manner.  If you have submitted an extension and you do not receive a timely response, please contact me or make a post about it in the TCE Talk area. 

After an extension is uploaded to the public download area, a post is made in the TCE News section regarding the extension.  Then testing and feedback on the extension can occur and be posted to that thread. 

One very important issue is that of licensing.  There is no way to cover all the facets of the different licenses there are out there, but rather I will just hit on a couple of key points.  GPL licensed extensions need the original source, patches, and the build instructions used to create the binary.  GPL'ed extensions cannot be accepted without these.  If an extension is a GPL Debian binary, then the source files available on the Debian server must also be submitted with the extension.  Be sure of the license and distribution policy before submitting as satisfying license requirements is a must.  If the extension is not under a restrictive license, the source and build instructions still provide valuable information about the program and can help tremendously when trying to debug an extension.  If in doubt, simply provide the source and build method as it only takes a minute or two at the time but is worth a lot later on. 

EDIT: Providing download links to the source is perfectly ok.  No need to upload what is readily available on the net.

EDIT2: If gmail is giving you problems blocking your extension, use bcrypt to allow it to be sent as then it cannot be scanned.

bcrypt extension.tar.gz

It will ask for a password, use "tinycore" as the password to keep it simple.

Hopefully the extension submission process will be a smooth and enjoyable experience for everyone.  We greatly look forward to your contributions and thank you for support of this project.  Any questions feel free to ask.

JW

[softwaregurl]

Thanks,
a couple questions:

1. What is the size limit for gmail?

2. Are there any special considerations to not get hung up in a gmail spam filter?

(I ask because I have never had a gmail account.)

3. The compile instructions for my apache-2.2.8.tcel were included in the comments of the .info.  Should this be common practice when they are very short?

4. You grabbed the tarball from the link I gave.  Does this overburden you?  I am on 900Mhz wireless...upload speeds are a little slow and I have nothing that supports resume on sending e-mail.  A semi driving past is just enough that the transciever has to renegotiate and things fail.  I do have other methods available, including downloading from one of my sites, if that doesn't work for you.

5. A clarification of file naming.  You renamed from tce to tcel.  I have seen something somewhere, but could not quickly reference it.  As far as standardizing the name...[app name]-[version]?  I am thinking apache-2.2.tcel would have been a better choice as I try to keeps up with the latest updates.  What is the best way to indicate a "hacked" version?

Thanks again,

[Juanito]

...
5. A clarification of file naming.  You renamed from tce to tcel.  I have seen something somewhere, but could not quickly reference it.  As far as standardizing the name...[app name]-[version]?  I am thinking apache-2.2.tcel would have been a better choice as I try to keeps up with the latest updates.  What is the best way to indicate a "hacked" version?

The "l" indicates that the extension libs are in /usr/local/lib and thus "ldconfig" is invoked by "tce-load" once the extension is loaded. In the same vein, an "m" indicates that the extension contains kernel modules and thus "depmod" is invoked once the extension is loaded.

It would be better to name the extension plain "apache" rather than "apache-2.2" so that when you update apache to a more recent version, you don't have to update any "dep" files that contain "apache-2.2"

[Jason W]

I believe the size limit of gmail is I believe 20mb.  So that would accomodate most any extension except those like Xorg. 

I am not sure what gets caught in gmail's spam filter and what doesn't, but what is caught is kept in the spam folder which is now empty.

It is fine to have the compile instructions in the info file.  I overlooked that at first, and quickly emailed back saying I saw it and that is was good.  Either a seperate file or in the info file is ok. 

I am more than happy to fetch the source from a link provided.  My recent playing with dialup has reminded me of how spoiled I am with my 3.0 Mbit DSL connection.  It is no burden to me at all and in fact me fetching source from a link costs me no time but saves others time.  Either way for me the download time is the same.  I just was in the old habit of including source myself when I uploaded but it is in no way a requirement; a link is fine.

As for extension naming, I added the "l" since there were shared libs in the exetnsion that needed ldconfig called upon for httpd to start without error.  I just added it instead of emailing back asking you to.  In the future if there are small clerical errors I will note any changes made in the info file by a response email.  Of course, I will not edit the info file for content or make any changes to the extension itself.

With library extensions it is by far the best not to include the version name in the extension as that causes a lot of .dep files to have to be adjusted when the library extension is updated.  For instance, gtk+-2.tcel can be updated without having to edit the content of any .dep files that call upon it.  If if were named gtk+-2.12.11.tcel, then of course all the .dep files calling on gtk2 would have to be edited if gtk2 was updated to gtk+-2.12.12.   But for apps that are not libs and do not have other extensions depending upon them, like leafpad, then it is not so important.  But still I as a general rule leave the version number out of the extension name.  Me, I would call apache-2.2.8 as apache2.tcel since there is also an apache 1.x out there.

If by hacked version you mean that non-standard patches were applied to an app or you changed the source on your own, then uploading the patches with the build info and mentioning that in the info file would suffice.   I would mention it in the description as well.  Sorry if I misunderstood the question, I think that is what you were asking.

I hope this helps. 

JW

[softwaregurl]

I was mainly thinking of complying with a license for hacked versions.  I will continue with apache specific stuff in that thread.

Tons of great info, thank you much!

[softwaregurl]

I would respectfully request that those who post to TCE News do like Jason W and include the text of the .info.  It is helpful for reference (and will also increase search hits).

cross ref http://forum.tinycorelinux.net/index.php?topic=417.0

Thanks All

[Jason W]

One thing that  would be helpful is if we indicate in the info file whether or not an extension is PPI compatible, meaning it is installed beneath /usr/local so all files are available upon reboot using tclocal mounting without having to reload the extension.  I am in the process of updating my relevent info files indicating this with something like this in the Comments section:  "This extension is PPI compatible."

Though most extensions meet PPI criteria, there are some that are not and knowing which is which will facilitate using PPI.

[Jason W]

All new extensions that are submitted are supposed to get the "TESTING" label, and I normally put that in before uploading the extension.  But I tend to be forgetful at times and it would help me out a lot if "TESTING" was already added at the end of the description line in the info file before the extension is submitted.  It doesn't sound like much but it would make a big difference for me not to have to remember that extra step.
Thanks.
JW

[Jason W]

We now have file lists for each extension in the repo.  They are named extension.tce.list or extension.tcz.list.  It was decided that extensions that make use of file lists are best supported by hosting the lists on the server rather than have the base system create them.  That way no one pays a performance penalty.  And file contents of an extension is useful to know anyway.  For anyone who does not know, the lists can be created quite simply.  For tce's:

tar -ztf extension.tce > extension.tce.list

For .tcz:

mkdir pkg
mount -o loop extension.tcz pkg
cd pkg
find `ls` -not -type d -not -name user.tar.gz > /tmp/extension.tcz.list
## if there is a user.tar.gz;
tar -ztf user.tar.gz >> /tmp/extension.tcz.list

There are other ways to list a tcz's files, but the above is the simplest.  On the server, the files in the user.tar.gz are listed seperately in the same file.  See compiletc.tcz.list for reference. 

It would be helpful to include the file list with each submitted extension.  As always, don't hesitate to ask if there are any questions.  I will this evening post the script I use to make tcz file lists so they will be the same format if folks want to use it to save time.

[Jason W]

Hi folks,
I ask that you bcrypt all files submitted to ensure their integrity.  For those new to bcrypt, it is simple:

bcrypt tarball.tar.gz

It will ask you for a password, use the password "tinycore". 

Here is a concise rundown of the recent additions to the guidelines not mentioned in the wiki:

1. Include "TESTING" in the description of the info file.  (This is the one I otherwise tend to forget.)
2. Indicate in the info file if the extension is PPI compatible.
3. Send extensions and files in a bcrypted tarball. 
4. List files are optional, but they are helpful to make and examine to make sure the extension contains the right files and does not have base directories included.  I create a file list as part of the QA process, so no need to send one in.
5. If the extension is GPL or similar that requires source, build instructions and patches are  required to satisfy the license.  Or a tarball of the configured source would also suffice.  If build instructions and patches are sent in, I can fetch the source itself as long as I have the version number.

Thanks everyone for their contributions, and as always don't hesitate with any questions.

[^thehatsrule^]

Split off-topic discussion to http://forum.tinycorelinux.net/index.php?topic=1112.0

[Jason W]

There have been occasions that users have posted links to their extensions instead of submitting them.  The team has discussed this issue and agrees that submitting extensions is the way to publish your extensions, posting links is not.  While posting links to extensions seems like a harmless practice, posted links have not been reviewed for legality, form, or potential malicious code before they are available for download.  TC only distributes software that is legal for us to distribute.  And though I can't review every line of source code in an extension, I can and do examine scripts as well as general extension content.  I have faith in the TC community when it comes to the issue of malicious scripts in extensions as I know no one here would not try to harm other users, but remember that anyone can sign up on the forum and begin posting.  I would rather our community have the distributed extensions go through the basic checks before being available to all.   As well as the extensions be available through the appbrowser for all to enjoy.

I hope you all understand.  If you have in the past placed links to extensions please do not feel offended.  But do realize that the submission process is open to all and everyone is invited to contribute.  Submit your extension and it will be posted within a day in almost all cases. 


Posted links to extensions from now on will be deleted by a team member as a matter of policy. 

There are about 450 extensions in the TCE area now, and we thank the community for all your work.  Keep the extensions coming this way.

EDIT:  Oh, and if you have trouble with gmail or any aspect of submitting extensions just contact me or post about it in the forum and something will be worked out ASAP.

[Jason W]

Now that we have two major versions of TC, please specify which repo you have built your extension for so I know where to put it.

Thanks.

5.6.09:  This is very important now that we have two repos and things built on 1.x don't necessarily just work on 2.x.  PLEASE specify which repo each extension goes in.

[richardbronosky]

I sent an email to the tcesubmit address above on 2010/08/22 and never heard a response. I'm interested in doing Texas Instruments msp430 development and would like to see packages added to enable this. I was wondering if I would be duplicating anyone's effort.

[Jason W]

Hey,
I don't know of any outstanding mail that I have not processed, let me look and see.  There is a chance it has fallen through the cracks.