some tc-ext-tools buildscripts

[althalus]

For as long as I've been using tiny core, I've had a few packages I've contributed, and a bunch of packages that weren't polished enough, and were unlikely to ever be polished enough, to actually submit to the repo, but still would have liked to share.

A few days ago I stumbled across Arslan's package build system (http://code.google.com/p/tc-ext-tools/), and sort of instantly decided I liked it. It allows for a much more reproducible result, and gives me a way to share extensions I'm not happy enough to submit with the rest of the TC community, in a fashion.

I've decided put my package scripts up in a github repository here: https://github.com/althalus/tet-packages

There aren't many packages there yet, but over time I'll add more. Hopefully someone will find some of them useful!

[Arslan S.]

Hi althalus
If you have a google account i can add you as a contributor so you can submit your packages.

So far i havent thought of a procedure for users to submit their packages

[althalus]

Hi althalus
If you have a google account i can add you as a contributor so you can submit your packages.

Cool, I'll drop you a PM with some details.

So far i havent thought of a procedure for users to submit their packages

One easy option would be switching to git and github. Then people can submit pull requests for their packages, and maintainers can check that requests meet specific requirements (is the common file set up right, does the package build, are docs correctly split out etc) before accepting the pull request. There might be better options, given a few more minutes thought than I've given it so far, especially given the current repo is SVN...

[solorin]

thanks for sharing, althalus. I too have numerous builds scripts in the same state.  github seems easy, but smells a bit like vendor lock-in. cgit or similar would probably be very easy to
set up on tc. it should also be fairly easy to set up continuous build server for integration testing.
then the repo maintainers could just pick up the polished builds from there. i believe this would improve the security and quality of the official repo.

svolli has also graciously shared his build system for tc; it seems a bit more git-oriented.
i haven't tried it so i won't presume to speak about it.

cheerio,
solorin

[althalus]

thanks for sharing, althalus. I too have numerous builds scripts in the same state.  github seems easy, but smells a bit like vendor lock-in.

Vendor lockin? How so? Git's nature makes vendor lockin more or less impossible, unless you get over-attached to their bug tracker, or something. If github closes down, it would be a very simple (but potentially time consuming) matter for me to up and move all of my repos to bitbucket, or set up gitlab or cgit on a VPS.

cgit or similar would probably be very easy to
set up on tc. it should also be fairly easy to set up continuous build server for integration testing.
then the repo maintainers could just pick up the polished builds from there. i believe this would improve the security and quality of the official repo.

Good points. I haven't actually done much of anything substantial with CI.

svolli has also graciously shared his build system for tc; it seems a bit more git-oriented.
i haven't tried it so i won't presume to speak about it.

Maybe I'm having a bit of a silly moment, but I can't find svolli's work - can you send me a link?

[Rich]

Hi althalus
Maybe solorin was referring to this:
http://forum.tinycorelinux.net/index.php/topic,2056.msg10947.html#msg10947

[althalus]

Ah, thanks Rich. I'll take a look when I'm feeling a little less stupid.

* althalus goes to find more coffee

[solorin]

Vendor lockin? How so? Git's nature makes vendor lockin more or less impossible, unless you get over-attached to their bug tracker, or something.

yes, technically you are right.  and i do understand the awesome nature of git's design.
i guess i should have said github smells a little like facebook.
chalk it up to paranoia, i mean it in the sense that github might slowly become synonymous with git (for the uninitiated), much like how facebook is slowly becoming synonymous with social interaction (for a certain portion of global society).

for example, just check out how many advertisements and corporate logos are on git's 'official' website, and what percentage of links on the front page point to github. in fact, you'll be directed to download the source from them, and not, for example, a less commercial entity like kernel.org.

people adopt and discard technology quickly,
people are attached to their society more permanently.
it's the web 2.0 version of vendor 'lock-in'.

hey it's just a minor critical commentary. i do think they do good work, and the website is spiffy.
also currently the corporation seems like a good community member, and i find that the way they organized their company in the beginning to be a fascinating and intelligent template for an open business.

_and_ all this is *not* to say, that i *don't* appreciate and support your choices and efforts.

so thank you.

cheerio,
solorin

[solorin]

my comments about CI were more generally directed to everyone.

arch linux's model of community build scripts and official binary packages seems to work well for them.
tc official binary package repo wouldn't have so much pressure to include every submission in order to provide a wide diversity of linux software or cater to the wide variety of user requests - community build scripts fill that requirement nicely.

(just saw dmenu, awesome, b(o.o)d. been wanting a dmenu that doesn't pull in all of Xorg-7.x-lib)

cheerio,
solorin

[althalus]

arch linux's model of community build scripts and official binary packages seems to work well for them.
tc official binary package repo wouldn't have so much pressure to include every submission in order to provide a wide diversity of linux software or cater to the wide variety of user requests - community build scripts fill that requirement nicely.

Yes, Arch's AUR system is fantastic. I've often thought something similar for TC would be a great thing, but never quite found the right words for the idea to post the suggestion.

(just saw dmenu, awesome, b(o.o)d. been wanting a dmenu that doesn't pull in all of Xorg-7.x-lib)

Does dmenu run without Xorg-7.6-lib? (I haven't tested it on a base norestore boot yet)

I primarily wanted the token searching present in the newer dmenu. I haven't tested it all that extensively, but will probably submit it soon, since it's quite significantly newer than the version I submitted way back in 09. (Wow, it does not feel like THAT long ago that I first found TC....)

[solorin]

sorry if this too much thread drift.

http://hg.suckless.org/dmenu/file/e4e6952a605d/config.mk
line 11 seems to suggest that Xinerama can be commented out of the build.
which from my cursory examination of Xorg-7.x-lib.tcz and Xlib.tcz
seems to be the only library in the former that dmenu uses.

cheerio,
solorin

[Rich]

Hi althalus

Does dmenu run without Xorg-7.6-lib? (I haven't tested it on a base norestore boot yet)

You could just run:

Code: [Select]

ldd dmenuto find its dependencies. Then use AppBrowsers provides function to see which extensions provide them.
According to:
http://gentoo.linuxhowtos.org/portage/x11-misc/dmenu
dmenu depends on  libX11, though in Tinycore, that's provided by Xlibs, not Xorg-7.6-lib.
libXft and libXinerama may be required, which are provided by Xorg-7.6-lib.