Tiny Core Linux

Tiny Core Extensions => TCE News => Topic started by: Jason W on December 28, 2008, 12:39:24 PM

Title: Guidelines for extension submission
Post by: Jason W on December 28, 2008, 12:39:24 PM
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
Title: Re: Guidelines for extension submission
Post by: softwaregurl on December 28, 2008, 02:45:23 PM
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,
Title: Re: Guidelines for extension submission
Post by: Juanito on December 28, 2008, 02:53:10 PM
...
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"
Title: Re: Guidelines for extension submission
Post by: Jason W on December 28, 2008, 03:16:23 PM
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
Title: Re: Guidelines for extension submission
Post by: softwaregurl on December 28, 2008, 03:50:30 PM
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!
Title: Re: Guidelines for extension submission
Post by: softwaregurl on January 28, 2009, 06:59:57 PM
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 (http://forum.tinycorelinux.net/index.php?topic=417.0)

Thanks All
Title: Re: Guidelines for extension submission
Post by: Jason W on January 31, 2009, 07:23:26 AM
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.
Title: Re: Guidelines for extension submission
Post by: Jason W on February 17, 2009, 12:55:42 PM
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
Title: Re: Guidelines for extension submission
Post by: Jason W on March 10, 2009, 09:44:41 AM
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.
Title: Re: Guidelines for extension submission
Post by: Jason W on March 25, 2009, 11:08:39 AM
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.
Title: Re: Guidelines for extension submission
Post by: ^thehatsrule^ on April 09, 2009, 08:30:59 PM
Split off-topic discussion to http://forum.tinycorelinux.net/index.php?topic=1112.0
Title: Re: Guidelines for extension submission
Post by: Jason W on April 24, 2009, 06:46:10 PM
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.
Title: Re: Guidelines for extension submission
Post by: Jason W on April 27, 2009, 04:18:10 AM
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.
Title: Re: Guidelines for extension submission
Post by: richardbronosky on September 19, 2010, 07:21:14 PM
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.
Title: Re: Guidelines for extension submission
Post by: Jason W on September 19, 2010, 07:24:55 PM
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.
Title: Re: Guidelines for extension submission
Post by: Jason W on September 19, 2010, 07:26:30 PM
It was caught in the spam trap.   I have forgot to check it recently, sorry for the wait, I am tending to it now.
Title: Re: Guidelines for extension submission
Post by: CaptBill on September 30, 2011, 09:53:13 PM
Hi Jason,
I am having an issue with the fpc.tcz (freepascal) not loading correctly. I am live cd booting with a local tce directory. The problem seems that the file structure on my system is usr/local/bin/fpc and the fpc.tcz structure loads it as /usr/bin/fpc.
Is this an error with set-up on my end or is it a typo in the fpc.tcz? Should fpc.tcz run with the stock config or should I adjust my path somehow?

The compiler seems to load and work correctly. It is the IDE that hangs, apparently because the directories are not there. The IDE is "fp.exe" the compiler itself is "fpc.exe" to test it.

I have notified the creator (Arslan S)

Thanks in advance
Title: Re: Guidelines for extension submission
Post by: gerald_clark on October 01, 2011, 09:21:42 AM
No, fpc.tz has its files in /usr/local/bin.
fp.exe is not a Linux program.  Are you trying to run a Windows program?
Title: Re: Guidelines for extension submission
Post by: vinnie on October 01, 2011, 10:14:46 AM
Small O.T.: Jason, what do you think if your script "submitcqc4" would create a template for build-dep, packname.tcz.info (with autocomplete of pack name, dimension and date of creation) and empty packname.tcz.dep?
The request is for lust of completeness, it isn't absolutely vital  ;)
Title: Re: Guidelines for extension submission
Post by: CaptBill on October 01, 2011, 08:56:25 PM
No, fpc.tz has its files in /usr/local/bin.
fp.exe is not a Linux program.  Are you trying to run a Windows program?

Thanks,
I actually meant to say the source files directory for FPC (which contains  a specific file ppc386).
The  tcz contains a fc.cfg that appears to not see this ppc386. And it is a hidden file at /home/tc/fp.cfg which I cannot change without modifying the extension.
Looking closer, I think I was mistaken on the cfg not looking right. It looks to be correct after all.

And looking closer that means I really need to talk to the author on this, being a fpc configuaration issue.
And, hopefully, the fix is simply finding his working config for Tinycore.

Author, 'Arslan S', left no contact. Hopefully you know where to forward the message, would be great.

Cheers

exe hahaha oops (is it .so?)
Title: Re: Guidelines for extension submission
Post by: Rich on October 01, 2011, 09:29:41 PM
Hi CaptBill
This topic belongs under either   TCE Q&A Forum   or   TCE Bugs.
You can send Arslan S. a brief personal message and bring it to his attention. Click on  Members
at the top of the page and you can look him up.
Title: Re: Guidelines for extension submission
Post by: Jason W on October 02, 2011, 12:31:03 PM
About submitqc4, I would rather not get into building templates and trying to determine build deps, it is mainly for checking what is already there.

Title: Re: Guidelines for extension submission
Post by: vinnie on October 02, 2011, 01:44:00 PM
no, no; no determination of the dependencies, only the empty file.
The idea is that, once started submitqc4 on a new package, this pulls out all the required files, so that one should only worry about finish to complete built-dep and info file (but already having the structure) and the .dep, deleting it if don't need (pack with no dependencies).
In short, a little help for lazy people :P
Title: Re: Guidelines for extension submission
Post by: Jason W on October 03, 2011, 08:37:20 AM
Basically it comes down to that would be more stuff I would have to work on, debug, and maintain, and I really don't have the time resources to take on any more than I already have.  But there are some good routines in other folks' build scripts that do that very thing with the info and build-dep files. 
Title: Re: Guidelines for extension submission
Post by: vinnie on October 03, 2011, 11:59:52 AM
in fact this is not fundamental, it is just to talk about potentiality  ;)
Title: Re: Guidelines for extension submission
Post by: Scampada on March 31, 2015, 11:35:54 AM
Hey,
do I need to bcrypt the package before sending? There in the wiki was said that gmail provides enough security to do not so. Is it actual data?

In addition, I found no package named mp3blaster in official repo, so I believe it's all up to me, no need to agree with anyone?

I've built it for myself, it works (as tcz) and it depends on four small packages only, instead of a whole bunch of them in cmus dependence tree. mpg123 also requires only one or two dependencies and is quite small but it doesn't provide nice looking CLI GUI, playlists, file browser, doesn't play not only mp3 but ogg and flac and wav files too (and mp3blaster even can convert them somehow) and so on. I do not know if cmus does provide it too and what is it like, because it never worked for me. It chains so goddam many packets in dependencies, some X junk, and much more, and then I ran it and it won't start complaining of not finding some MORE libraries. I installed the required just fo' lulz and it still won't play for some more reason, I don't recall why. But anyway, is it good to install twenty or more dependencies for one CLI music player? mp3blaster is nice.

    [EDIT]: Removed color tag which made text difficult to read.  Rich
Title: Re: Guidelines for extension submission
Post by: Rich on March 31, 2015, 12:27:38 PM
Hi Scampada
The wiki used to say use bcrypt. Why that was removed, I don't know. Last time I submitted something I used bcrypt.
mp3blaster.tcz is in the TC4 repository and was submitted by juanito. As a courtesy, you should send him a PM to see if it's OK.
I removed the color tag from your post to make it readable.
Title: Re: Guidelines for extension submission
Post by: Scampada on March 31, 2015, 12:35:40 PM
Okay, I still have vague idea of repos for other versions, I installed TC a few mere days ago and checked only default one. OK, I will, thanks for the tip.
It looked strange indeed, I was trying to 'exclude' that part of the message with some kind of "offtopic" designation. There is no [offtopic] tag here, am I right?
Title: Re: Guidelines for extension submission
Post by: Scampada on April 01, 2015, 12:21:54 AM
Is there any coordination thread in the forum where one can find all actual and deprecated packages and their maintainers?
For example I had found and compiled for myself a tiny utility that can make screenshots in .png from framebuffer with almost no dependencies -- unlike some kind of scrot which has a pack of deps or fbdump which needs an additional utility to convert its output from ppm to png with e.g. NetPBM package which is huge and requires perl.
But I can't know if there is any similar utility in use or it once had been in use but is deprecated, or who's its maintainer etc. And it's rather difficult to find it through tce-ab.
(The package I found was written using a bit outdated libpng library standard, I have fixed it a little; it still throws a pair of warnings but it builds and works properly.)
Title: Re: Guidelines for extension submission
Post by: Juanito on April 01, 2015, 01:12:07 AM
you can use the apps gui to search tags on "screenshot" or similar, but this will show only the extensions  in the current repo for the architecture in use (x86, x86_64, etc).
Title: Re: Guidelines for extension submission
Post by: Scampada on April 01, 2015, 01:19:38 AM
you can use the apps gui to search tags on "screenshot" or similar, but this will show only the extensions  in the current repo for the architecture in use (x86, x86_64, etc).
Why, can't I do the same using tce-ab (K)eywords search?.. And exactly, I can search only in the current branch and only for my architecture. I had not found mp3blaster in there but it turned out it had been maintained some time ago.
Title: Re: Guidelines for extension submission
Post by: Juanito on April 01, 2015, 01:33:08 AM
did you try "screenshot" in the keywords search?
Title: Re: Guidelines for extension submission
Post by: Rich on April 01, 2015, 07:54:21 AM
Hi Scampada
As I recall Tinycore comes with a screenshot utility. Does it find anything if you enter:
Code: [Select]
screenshot.sh
Title: Re: Guidelines for extension submission
Post by: Scampada on April 01, 2015, 10:55:26 AM
did you try "screenshot" in the keywords search?
Surely. But it seemed to me that those utilities listed in the-ab hd too many dependencies each. I'm a bit faddish about *tiny-ty*. Maybe as a newcomer; I like the idea of *tiny-ness*. I like to *optimize*. Sometimes I do not know of something relevant and try to invent a bicycle though. Heheheh.
I've already edited some source files of a fbgrab ('make' threw errors for deprecated-style use of libpng) and it works for me and depends only of libpng. It's nice. Now I'm trying to build some console image viewers from some legacy sources which I believe need less deps. I know there are image viewers in repo but they look too big for me. I'm a *tiny-ac*. Well, it's maybe stupid but I seek simplicity. What is tiny is simple eh?
Wanna make a meta-package to bring all these tiny dep-less or not-very-huge-dep-list CLI utilities altogether to make a full environment. You install one not-very-huge package and right after that you'll have feature rich FB and ncurses-based movie and music players, image and maybe even PDF viewer, screenshot utility, text browser, torrent client, coffeemaker, all that crap onboard. I mean, just take emacs.

PS Use what is tiny, Luke
Title: Re: Guidelines for extension submission
Post by: Scampada on April 01, 2015, 10:56:57 AM
Hi Scampada
As I recall Tinycore comes with a screenshot utility. Does it find anything if you enter:
Code: [Select]
screenshot.sh
No I didn't... I'll take a look at this. I mean, it's of interest for me, is it tiny?
Title: Re: Guidelines for extension submission
Post by: Rich on April 01, 2015, 11:42:51 AM
Hi Scampada
It should already be included under  /usr/bin/
Title: Re: Guidelines for extension submission
Post by: Scampada on April 01, 2015, 02:23:50 PM
Quote
As I recall Tinycore comes with a screenshot utility. Does it find anything if you enter:
Code: [Select]

screenshot.sh
Hi Scampada
It should already be included under  /usr/bin/
No trace. (http://cs622630.vk.me/v622630788/26eff/nOPdlh-MGNI.jpg)

In addition, as far as I know there is NO console framebuffer image viewer for TC (in the current). They all require X.
Title: Re: Guidelines for extension submission
Post by: coreplayer2 on April 02, 2015, 12:06:10 AM
Am not exactly sure if this is the right place for this discussion but screenshot.sh is included in a normal tc install and can be found by installing the extension Xprogs.tcz

Code: [Select]
tc@box:~$ sudo find / -iname "screenshot*"
/usr/local/bin/screenshot.sh
/tmp/tcloop/Xprogs/usr/local/bin/screenshot.sh

Quote
Why, can't I do the same using tce-ab (K)eywords search?..
Also searching for screenshot under tce-ab > Provides:  results in the following, (which also lists Xprogs.tcz)
Code: [Select]
tce-ab
S)earch P)rovides K)eywords or Q)uit:p
Enter search term, e.g. iwconfig:screenshot
tce - Tiny Core Extension browser

         1. fox-doc.tcz
         2. fpc-src.tcz
         3. gimp2.tcz
         4. lazarus.tcz
         5. libimobiledevice-dev.tcz
         6. libimobiledevice.tcz
         7. lxde-icon-theme.tcz
         8. pilot-link-dev.tcz
         9. qt4-htmldoc.tcz
        10. totem-dev.tcz
        11. totem.tcz
        12. Xprogs.tcz

Enter selection ( 1 - 12 ) or (q)uit:



Also before submitting a new extension you may find testing with "submitqc6.tcz" useful
Title: Re: Guidelines for extension submission
Post by: Scampada on April 02, 2015, 07:55:29 AM
Thanks coreplayer,
I had checked tce-ab for (K)eyword 'screenshot'. I had seen all those entries but, I should remind that I want CLI-only environment atap (as tiny as possible). It's my goal to have as many utilities as possible without Xprogs and other big-sized dependence-packages. Look, fbgrab does only need libpng while screenshot.sh needs Xprogs, and the rest need lxde, gimp (which needs X), qt, totem etc. Install Xprogs just for a screenshot utility? Ew.
Now I have built fbida to have framebuffer only image viewer with no need in Xlibs or Xprogs or something. It needs: libpng, libtiff, libjpeg-turbo, libexif, giflib, fontconfig and some fonts package. It's able of zooming and even editing pictures, vieweing PDF documents (have not tested yet) and is pretty tiny, hey. I'll send them altogether, mp3blaster and fbida I think. And maybe fbgrab too. Just gotta make them clean, stripped and nice.
Title: Re: Guidelines for extension submission
Post by: Rava on April 27, 2015, 07:47:12 PM
In addition, as far as I know there is NO console framebuffer image viewer for TC (in the current). They all require X.

All I managed to code is a virtual console "framebuffer" copy script. ;)

It is able to copy the framebuffer from the virtual consoles of F1 to F6 (and also any others when "activated" in that system, usually that means non-commented in /etc/inittab, e.g. F8-F12)

Sadly, I was never able to figure how to copy from a xterm...  :(

It only works okay when the $COLUMNS of the virtual console and the xterm you might start it from have the same columns / width, e.g. 80 for both. Otherwise the needed folding will mess up the lines!
Usually the variable $COLUMNS is not exported and so cannot be read by the xterm or virtual console script. (It can be read when you type the line in the terminal by hand, but not in a script, that is)

Therefore you need to put export COLUMNS into /etc/profile. Or run that line beforehand on the VT or XTerm you want to run the script from.

Code: (bash) [Select]
#!/bin/sh
VERSION=0.6
MYNAME=ct
# ct (aka catterm) (c) Rava
# usage: ct 1 for cat of tty1 from other tty (console or xterm)
#  ct 1 1 for cat of tty and tail only 1 (=last) line, good for ctorrent or wget output or such.
if [ "$COLUMNS"x = "x" ] ;then
    echo $MYNAME V$VERSION - could not read \$COLUMNS - assume 80.
    COLUMNS=80
fi
if [ $# -eq 1 ]; then
    cat /dev/vcs$1 | fold -w $COLUMNS | sed 's/[ \t]*$//'
    echo
elif [ $# -eq 2 ]; then
    cat /dev/vcs$1 | fold -w $COLUMNS | sed 's/[ \t]*$//' | tail -n $2
    echo
else
    echo $MYNAME V$VERSION Unknown parameter - Abort.
fi

Cave! Some Linux use /dev/tty* while others use /dev/vcs* !
usually, both refer to the Virtual Consoles, but I never encountered a system that would use both, it is either tty or vcs!
Title: Re: Guidelines for extension submission
Post by: nitram on May 14, 2015, 09:43:33 AM
Hello.

I submitted an extension a week ago. Maybe it got lost in the shuffle. Thought i would post here to see what happened as i did not receive a reply and did not notice anything in the forum, recently updated tcz section or via Apps repos.

This thread indicates a typical 24-48 hour turnaround but that may have changed. I am also no longer sure if Jason handles submissions, as he now works on dCore. The submission was not encrypted but that no longer appears necessary.

Anyone process a rogue.tcz extension, emailed on May 7th?
Title: Re: Guidelines for extension submission
Post by: coreplayer2 on May 14, 2015, 03:01:51 PM
Don't worry, sometimes it can take a week or so
Title: Re: Guidelines for extension submission
Post by: nitram on May 14, 2015, 07:04:47 PM
Thanks coreplayer2...just anxious  :P
Title: Re: Guidelines for extension submission
Post by: JustinCB on June 02, 2017, 06:06:36 AM
...
Also before submitting a new extension you may find testing with "submitqc6.tcz" useful
Now it might be better to us submitqc7.tcz or submitqc8 when it hits the repository. 
Hi Scampada
It should already be included under  /usr/bin/
In the current repository at least screenshot.sh is in /usr/local/bin/

Also, more on topic, I sent several emails with extensions(one had a link to google drive because the .tar.gz was too big) in the last few days and haven't gotten any replies. 
Title: Re: Guidelines for extension submission
Post by: Misalf on June 02, 2017, 06:22:46 AM
It can take a few weeks for submitted extensions to appear in the repo.
Title: Re: Guidelines for extension submission
Post by: JustinCB on June 02, 2017, 07:51:45 AM
It can take a few weeks for submitted extensions to appear in the repo.
OK.  I'll be patient.  Is the number of extensions being submitted so high that whoever it is that checks them has a pipeline/waiting list of extensions to check? 
Title: Re: Guidelines for extension submission
Post by: coreplayer2 on June 02, 2017, 08:10:22 AM
I'm also waiting for a number of submitted extensions to be posted..

Somehow the last 3 weekends seem to have been missed, but there's always this weekend and next weekend before I start to panic :)
Title: Re: Guidelines for extension submission
Post by: curaga on June 02, 2017, 09:33:05 AM
He's just busy in general, I guess.
Title: Re: Guidelines for extension submission
Post by: JustinCB on June 06, 2017, 09:49:27 AM
Mine just got processed, so I guess yours will be processed soon too. 
Title: Re: Guidelines for extension submission
Post by: JustinCB on October 03, 2017, 09:20:23 AM
I sent two batches of extensions. The first went fine, but the second kept getting rejected by gmail, so I had to use bcrypt(I've never had to do that before).  They haven't appeared yet to my knowledge, but I'm sure you're busy. 
Title: Re: Guidelines for extension submission
Post by: Rich on October 03, 2017, 10:10:52 AM
Hi JustinCB
Step 6 listed here:
http://wiki.tinycorelinux.net/wiki:creating_extensions#abbreviated_steps
does mention to  bcrypt  the archive, though I thought at one time there used to be directions on how to  bcrypt  the archive
here in the submitting section of that Wiki page:
http://wiki.tinycorelinux.net/wiki:creating_extensions#submitting
As I recall, it also used to say to use the password  tinycore  when  bcrypt  asks.
Title: Re: Guidelines for extension submission
Post by: Lukasz032 on November 09, 2017, 07:22:19 AM
I've submitted some extensions on October, are there any delays in processing? I haven't gotten any confirmation since then :)
Title: Re: Guidelines for extension submission
Post by: Misalf on November 09, 2017, 07:28:02 AM
It can take a few weeks for submitted extensions to appear in the repo.
;)
Title: Re: Guidelines for extension submission
Post by: JustinCB on July 12, 2018, 06:36:41 AM
Hi JustinCB
Step 6 listed here:
http://wiki.tinycorelinux.net/wiki:creating_extensions#abbreviated_steps
does mention to  bcrypt  the archive, though I thought at one time there used to be directions on how to  bcrypt  the archive
here in the submitting section of that Wiki page:
http://wiki.tinycorelinux.net/wiki:creating_extensions#submitting
As I recall, it also used to say to use the password  tinycore  when  bcrypt  asks.
By the way, the wiki page has a mix between outdated & recent info, which is often confusing(in 2016 it only had info up to tce 4.x but then in 2017 & 2018 I did a half-arsed job updating it :-[ ).  We need someone who's a better writer & is willing to update it properly.  The rest of the wiki needs to be updated too, but less so than that page. 
Title: Re: Guidelines for extension submission
Post by: aus9 on July 12, 2018, 06:39:38 PM
bcrypt IMHO should be removed because if you read the bottom lines

Files part of an extension package are Gmail neutral and accepted for delivery, no need to encrypt.

I added gmail has a size limit of 25 Mb to that section.

(2) I added a section for daemons under info that says Please show full pathways to start daemons in your info file. TC does not condone starting daemons in your tce.install script.
but me thinks it may also have to be mentioned in the custom install script section too.

Personally I use a build dir for a random package....I squash it as a TCZ and send it as that file
because if I have some new build dependencies......I sometime use the same email to keep it all together

my fav TCZ checker is very tolerant of my ways ;)