big_bass ,Amigo, ttuuxxx chit-chat zone?

[ttuuxxx]

ttuuxxx
great to hear you made a package for puppy
I always burn with K3b when its big
simple stuff I burn with grafburn
puppy needs more choices for burners


great news
Joe

Yes I agree, It took 9 packages to compile it from scratch. I managed to get it down to 512kb pet package, which is really good because it has its own burning backend, where as Pburn uses a default 2mb backend, which includes all that schilly stuff, I think this is a great alternative, and might spark a bit of change, The second package I built is gstreamer backend, I have it up and running, but haven't released it yet, due to testing, but what this one will give, so that I've read, is the ability to convert different video file formats, Plus being gstreamer based, I'm going to see if I can get one of those Gstreamer video players to work. If so that would be a great change. Possibly Xfburn +Gstreamer + Video player, could equal Gxine+Pburn+Burniso2CD+schilly backend. and save a few MB compressed along the way
ttuuxxx

[amigo]

If you create a link named cdrecord which points at the cdrskin program, libburn can replace cdrttols almost entirely. cdrskin emulates the syntax of cdrecord. Creating the link lets cdrskin subsitute for cdrecord for use with other programs which call cdrecord.
You may want to look at and possibly include the libisoburn package that goes with libburn/libisofs.

[big_bass]

how to check the dependencies to get the
other correct packages for xfburn
installed on my slackware box

which would be the same process for puppy
since this tool works for both

The GUI dependency checker at this link below
http://www.murga-linux.com/puppy/viewtopic.php?t=38379

gives you this out put file that I attached you can see that
all the dependencies were met
before uploading a pet / tgz package


this will be a valuable tool now more so
with the multiple puppy builds with woof

sorting out from the master host machine as a reference
of the working package

then running again on the new target host machine
it is much easier to find conflicts in libs and their
installed directories

but now you have more information
to correct any irregularities quickly

big_bass

[amigo]

big_bass, if you first create the package using src2pkg and use the -E and -A options together, it will give a much nicer and useful output of the depends as it will list the packages that contain the dependencies. For now, you should find it easy enough to create your pets from the finished PKG_DIR (in /tmp unless you have changed the defaults.) I'm gonna work on writing an extension to src2pkg which will whip out pets with the same ease as tgz packages -even though I don't think much of the pet package format. Meanwhile, all you should need to do is move ./install/doinst.sh to ./pinstall.sh inside the finished PKG_DIR and then run dir2pet in there, I think.

[ttuuxxx]

If you create a link named cdrecord which points at the cdrskin program, libburn can replace cdrttols almost entirely. cdrskin emulates the syntax of cdrecord. Creating the link lets cdrskin subsitute for cdrecord for use with other programs which call cdrecord.
You may want to look at and possibly include the libisoburn package that goes with libburn/libisofs.

Hi amigo I tried that with XcdRoast and it didn't reconise the version of cdrecord and then it crashed, but if I replace it with the compiled cdrecord it works, I think its more than just linking, maybe a wrapper.
ttuuxxx

[big_bass]

amigo (Gilbert)


your source to package src2pkg is an excellent tool
and you know that I use it frequently
with great results and I can't say thanks enough for it
friend

the options you added are great to have
for dependencies and make you work even better
the formatting of the dependency info is very different than my approach
-----------------------------------------------
the small GUI I made is a handy tool
repeat just a small handy tool
just one script from a front end GUI packing tool


that anyone can use without compiling a package
or even knowing how or even have a compiler .
It is for new user's to sort dependency problems
by uploading the generated depend-txt

to the original packager to verify the integrity
of the installed package

the reason is
there is quite a lot of mis matched packages floating around
and this is an attempt to bring some order to the
current problem on puppy

*I am working on expanding that to a self checking tool also
but will be quite complex now with four major distros and dot pups
and multiple older puppy versions

or for the advanced user that has no dependency
tools or has them but wants to save time and have the dependencies logged in a text file


Gilbert
with the multiple future puppy builds
I am and remain to be your biggest supporter on puppy for src2pkg
which I mostly compile on slackware because I have the same kernel
on my box

an observation
I personally only need a *.tgz
there are solid guide lines to follow

but if you decide to add *.pet
there will be many things to sort out

and puppy has a built in *.tgz to pet already
which is easy to use

I always hand edit the final puppy packages
to verify them (just a personal habit )

I know that src2pkg
needs to be added to the new puppy build system
and any way I can help iron out puppy related issues
let me help out


Joe

[ttuuxxx]

Hey bigbass were almost on page 3 now, just the 3 of us, Maybe you should re-title it, Bigbass,Amigo,ttuuxxx chit-chat zone?
we could sticky it and have a hangout place,lol
ttuuxxx

[big_bass]

Hey bigbass were almost on page 3 now, just the 3 of us, Maybe you should re-title it, Bigbass,Amigo,ttuuxxx chit-chat zone?
we could sticky it and have a hangout place,lol
ttuuxxx

done .....check the thread title now



Joe

[ttuuxxx]

thats funny, made me laugh,
I contacted the developer of Graveman burner, first I mentioned that he has that a future update is comming sept.2006 lol I said I guess you missed that date,lol So anyways I asked him if he is thinking about converting over to libburn and well he hasn't replied back yet but that was about 12hrs ago. I'll let you know if he says anything.
ttuuxxx

[amigo]

tuuxxx, I wasn't sure how compatible cdrskin would be with any other programs. One would probably have to search and try several and perhaps your idea about using a wrapper would work if xcdroast is checking the version number. come to think of it, I read in one of the long-long threads about schilly that xcdroast was written especially to use cdrtools. I usually use another small burner program called simpledcdr (and simplecdrx). I'll try it and see what happens.

Now both of you, I've just today gotten src2pkg creating pet packages pretty handily. I'll want to iron any obvious problems for a day or so and then I'll turn you both onto it for further testing. It really only took a few lines to make the basic change, but of course I'm adding in some extra helpers -like automatically writing the $NAME.pet.specs file for you and converting the doinst.sh files.

The pet format is pretty lame actually -as far as I can tell it doens't handle any BUILD or RELEASE number?? That makes it impossible to use pet packages in an update scheme...
I really think that Puppy would be better served by using a different package format which handles a few more features.
BTW, the slack-required files that src2pkg produces are meant to provide compatibility with the slapt-get system. Of course, $NAME.pet.specs has a field for dependency on official packages, but a routine would be needed to translate the package database info -it really would be much slicker if Puppy just went to using slackware-type packages for everything. I mean, every program should be part of a package -no 'core' which is built and installed 'in bulk'. This modularity would then lend itself to easier customization of the distro into smaller, larger or special purpose installations. It would also provide a sane method for updating things packge-by-package with or without slapt-get.
I've done some work on the pkgtools suite over the last few months -slowly- as I figure out a way forward with a modified package format. One of the things that pkgtool does not do, that maybe petget can and others surely do, is to be able to run a script *before* installing the files. Of course, debian and rpm systems also have the ability to run scripts before and after un-installing as well. The pkgtool I am writing will be able to handle all these, plus some extra database files -like the slack-provides which src2pkg already produces. My pkgtool also already can install packages compressed using bzip2 or lzma as well as gzip and src2pkg can already create these.
Using lzma can save a lot of space on an install CD...

Most of the tricks that src2pkg already does -like culling language files, stripping aggressively and compressing binaries are already usable for pets. I do have in mind to write a routine which will split or segregate a package to separate the devel, lang, doc and runtime components. Oh, src2pkg can already create archives of the documents for you and use bzip2 or lzma for man-pages.

You can also write extensions to src2pkg to modify its' behaviour, so it would pretty easy to have a routine which would strip out unwanted materials. I haven't written routines to do such drastic things as I'm kind of a stickler about conforming with the licenses and try to make src2pkg produces excellent quality packages which are as complete as possible. I'd much rather see Puppy come a little closer to that criteria than to see src2pkg simply try to produce the smallest package possible. That 'smallest possible' criteria tends to cripple....

I'll get back to you both in a day or so with a tryout-version. tuuxxx, I don't have youre-mail address, I think. E-mail me at amigo@ibiblio.org so I have yours. Include src2pkg in the subject line, please.

[ttuuxxx]

tuuxxx,
I'll get back to you both in a day or so with a tryout-version. tuuxxx, I don't have youre-mail address, I think. E-mail me at amigo@ibiblio.org so I have yours. Include src2pkg in the subject line, please.

Sounds interesting enough, here's my email,
looking forward to it
ttuuxxx

[amigo]

I have e-mailed you both with copies of the current devel version of src2pkg, tar-1.13 and pkgtools. Hope your inboxes can handle it.

[ttuuxxx]

I have e-mailed you both with copies of the current devel version of src2pkg, tar-1.13 and pkgtools. Hope your inboxes can handle it.

Sorry I checked my gmail and nothing, maybe upload it to a server ? and post a link?
ttuuxxx

[amigo]

Sorry mate, I was missing a 't' in your email address. I've resent the email. I don't want to upload a pre-release version because my site gets automatically mirrored and I don't want stray versions floating around.

[01micko]

Does any of this help me get a faster 486? (perhaps some)

[ttuuxxx]

Does any of this help me get a faster 486? (perhaps some)

Naaaa mick its another way of compiling, but the package to do it is 2.6MB, so that would probably slow down your beast, and I bet you don't compile on it to start with.
What could make it faster is reduce the bloat in it, even if your using say fatfree, check out your usr/libs directory , use rox and arrange the libs from biggest to smallest size and see what you can delete.
click the show extra details button on rox then click change sort criteria so it looks like below

[big_bass]

Hey Gilbert

I received your email and package thanks
if you do any updates post a note here in this forum
thread

wouldn't want to miss it



I sent you an email (a long one I may add )

Joe

[big_bass]

Does any of this help me get a faster 486? (perhaps some)

indirectly a 486 can be made very fast if you want to spend the time to dedicate
a build for older machines only

and compile everything from source

and that's where src2pkg would make the job less work

the greatest obstacle with older machines is RAM

the recent slacker pup I made could be made to run under 32 MB
at the moment I use 57MB with nothing else removed lets see what woof is doing in terms of RAM

I don't know it may be a better choice
if so have a go at it

it would be interesting to view the results of the free and used
memory with the new woof build
tested on a 486 (my beloved 486 /100mhz compaq gave up the ghost)

a very technical explanation:
all chips contain smoke that is the magical
substance that makes things work
and this smoke is tightly sealed in the chip
when the smoke comes out of the chip
the ghost left and it no longer works

so, I can't test 486 anymore
big_bass

[01micko]

Big_bass

I made apup from woof and that was supposed to be broken but I got it to work, albeit with bugs.

So I guess I would aproach this with a slack pup build from woof, strip what is not needed, (ie, turn off some switches in PACKAGES_DISTRO_SPECS_slackware), use src2pkg to strip further?

[01micko]

Sorry to hijack your little triangle....
downloading packages now for spup...(woof)
Some tips? Safe to strip? (486 50MHz, 32ram)

Printing is gone, so what else? SMB? (not needed)

I notice all slackware packages are "'whatever....i486", unlike Arch all i686.

Bear in mind I'm fairly new here.

Can I right click on stuff and go, "yahooooooooooo"??? (ttuuxxx ), hmm perhaps.

The 486 has a burner by default, probably useless, unless I want to burn small.

Gonnna fire up my old 486 thread, leave you blokes to your 'chit chat'!!!!!

Jeff, Puppy does need better burning, sometimes bloat can be misleading.

Amigo. Once you recommended 'dash' to me, seems BK has found it useful too (speed wise), . check his blog