But I see multisession as a way to protect and extend puppy into a rolling release method. The strong negative with rolling release is returning to last good state, that is dead easy with multisession puppy, no complex source version control, no accidental overwrites or loss of key data.
Would like to be able to label the sessions, verses the current date-time stamp naming method. And merge the two ways that multisession is done by BK and FatDog64.
With session labels (default to date-time) we can label key points or packages worked on, to aid in recovery.

ref:TedDog: Remove -J from iso file setting, was getting same error at 100% of the time in one stress test on a effort doing something else. Just passing that info along..Last edited by scsijon on Thu 02 May 2013, 02:00; edited 1 time in total

Got a 'little' frustated and tried installing it the manual way, copying cd files into a directory, setting grub lines up and rebooting.

It all worked on, once I went in and set the video= up on the vmlinuz line.

Savefile created ok and all seems ok on a reboot, but was not.

So it looks like the boot problem relates to the loader, not the O.S.

regards.

EDIT:
Savefile problems
It seems to need to be in the bottom level of the partition, a reboot when it's at a higher level, such as a frugal build (eg /dev/sda7/slackbones64/sbsave.ext4) gives two problems one it's not found by name and secondly it's not found by location. I seem to have to have it as /dev/sda7/sb64save.ext4.

EDIT:
Savefile problems
It seems to need to be in the bottom level of the partition, a reboot when it's at a higher level, such as a frugal build (eg /dev/sda7/slackbones64/sbsave.ext4) gives two problems one it's not found by name and secondly it's not found by location. I seem to have to have it as /dev/sda7/sb64save.ext4.

Would like to be able to label the sessions, verses the current date-time stamp naming method. And merge the two ways that multisession is done by BK and FatDog64.
With session labels (default to date-time) we can label key points or packages worked on, to aid in recovery.

Interesting idea, but how do you reconcile this with the fact that every multisession-save only saves a snapshot of what has changed (rather than the entire state)? I mean, when you say you want to load sesssion "x", for it to make sense you also need to load every session created before session "x" ...

But I see multisession as a way to protect and extend puppy into a rolling release method. The strong negative with rolling release is returning to last good state, that is dead easy with multisession puppy, no complex source version control, no accidental overwrites or loss of key data.
Would like to be able to label the sessions, verses the current date-time stamp naming method. And merge the two ways that multisession is done by BK and FatDog64.
With session labels (default to date-time) we can label key points or packages worked on, to aid in recovery.

I realize that you and others are very into multisession on discs. However, It's not anything that fits in with my needs. Since its not something that I need, I've never spent much time looking into how it works. So its just not worth my time to spend trying to work it into this project.
But that's neither here nor there, the fact is Slackbones is meant to be a base platform for someone else to be able to take and use to build their own release. As such If someone wants to add multi-session, they are more than welcome to. Someone can also make a writeup on how to add it to the base iso for everyone elses benefit. There are tons of things "I" would have in slackbones if it was just for me... but thats not what this is for. Likewise, I'm not building this for anyone particular persons preferences. It's a blank slate so that each person can build what 'they' want.

The fact is all the benefits you talk about with a mutli-session, could be done the same with a regular save file... Just date changes in each folders.
It would just take a recode of the current setup to have the same 'benefits' that you claim multi session has.
I personally will not do that, because I'm not interested in it. But the beauty of OSS is that anyone can do that and share it with everyone else.

I think the booting issue is due to my remaster. Since it was happening, and then the fixed ISO didnt occur for the person who had trouble the first time, I think its an issue during the ISO burn.
I got back in from a trip ealier today and havent had much time to tinker at all.
Let me know about the devx .h file.
I do know the devx with slackbones is ALOT slimmer than with Fatdog, so that was probably due to something thats not included with the dev stuff for X. You'll see only a few X packages in there. Basically what was needed to build the GUI and thats it.

Here is whats in the devx for SB1.2

Code:

### This file contains the list of slackware packages to use.
###
### Comments must start with # at the start of line
### Blank lines ignored

FYI, slapt-get is included so you can install packages from the official slackware repo, if you know you need them. If you dont know much about slapt-get you can read up on it Slapt-get FAQ.
You can run it from the command line or from within X.
You can also install the gslapt package and use the gui interface that's been made for it.

But I see multisession as a way to protect and extend puppy into a rolling release method. The strong negative with rolling release is returning to last good state, that is dead easy with multisession puppy, no complex source version control, no accidental overwrites or loss of key data.
Would like to be able to label the sessions, verses the current date-time stamp naming method. And merge the two ways that multisession is done by BK and FatDog64.
With session labels (default to date-time) we can label key points or packages worked on, to aid in recovery.

I realize that you and others are very into multisession on discs. However, It's not anything that fits in with my needs. Since its not something that I need, I've never spent much time looking into how it works. So its just not worth my time to spend trying to work it into this project.
But that's neither here nor there, the fact is Slackbones is meant to be a base platform for someone else to be able to take and use to build their own release. As such If someone wants to add multi-session, they are more than welcome to. Someone can also make a writeup on how to add it to the base iso for everyone elses benefit. There are tons of things "I" would have in slackbones if it was just for me... but thats not what this is for. Likewise, I'm not building this for anyone particular persons preferences. It's a blank slate so that each person can build what 'they' want.

The fact is all the benefits you talk about with a mutli-session, could be done the same with a regular save file... Just date changes in each folders.
It would just take a recode of the current setup to have the same 'benefits' that you claim multi session has.
I personally will not do that, because I'm not interested in it. But the beauty of OSS is that anyone can do that and share it with everyone else.

I understand where you are coming from, and like that you offer a blank slate to build with. There is a concern that lot of the essence of puppylinux is being dropped, with slackbones, multisession has be a core with puppy since version 1.05. If this trend continues when does it stop being a puppylinux? There has been barebones before that contains core properties (but, no browser , only one editor, one calculator, no games, one set of icons, vesa X only etc) so It can be done and core retained.
This is not to minimize your work getting this out, if it was easy I could have done it getting Slackware, puppylinux, and 64bit together is an achievement.

I understand where you are coming from, and like that you offer a blank slate to build with. There is a concern that lot of the essence of puppylinux is being dropped, with slackbones, multisession has be a core with puppy since version 1.05. If this trend continues when does it stop being a puppylinux? There has been barebones before that contains core properties (but, no browser , only one editor, one calculator, no games, one set of icons, vesa X only etc) so It can be done and core retained.
This is not to minimize your work getting this out, if it was easy I could have done it getting Slackware, puppylinux, and 64bit together is an achievement.

I think it is a valid concern. How "bare" can we go? We'd like to think that sb64 is as bare as it can be which is still easy for developers to add and install additional packages.

Initially we had plans to go only with CLI. And then we added Xorg. And then we added GTK so that lxpanel and rox can run. And then we added the firefox. Ok, that was too far, so we dropped firefox. We added the "essential" scripts that enable creation of savefile (and multisession). But you will find that there are other Fatdog scripts which aren't in - others may want to do it in their own way (e.g. drop lxpanel/rox and replace with pcman/spacefm/whatever, or drop GTK and replace that with Qt, or even more radical drop Xorg and replace with Wayland), in which case those Fatdog scripts (which depends on GTK and Xorg) would not make any sense at all.

I guess at the end of the day it depends on what you want to do with it. For some sb64 may be too bare, for others it may be too big already. That's why it is good to hear feedback like this, and also for those who really use sb64 as a base - see what important features are considered lacking, and what excessive features that needs to go away, so that we can tweak it for next release.

To answer the specific question: multisession-save is indeed included with sb64.

scsijon,
To add to what Q5sys has already said - you can also use "slackpkg" to install official slackware packages (both binaries and libs and headers), in addition to "slapt-get" (CLI) and "gslapt" (GUI). By the way, slackware doesn't really split packages between binaries and devx packages, when you get a package you've got everything: binaries, libs, and development headers._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Please read the note at the top if the first message (dated 7 may) for some important information.

There are quite a few changes and improvements between what your current one is and the new one, so it could be well worth scanning the few pages of the thread before installing.

Any reports relating to JWM and the build should go in the JWM thread with a title including '64bit' so I know which build I'm dealing with. Also Joe monitors and ocassionally answers in the thread,

Hopefully a X86_64 jwmconfig2 will appear soon to match your systems.

P.N. This was built on and initially tested on fatdog64 v620, I have yet to test it on slackbones64, so there may be other packages required to deal with dependancies, at the least it should start from a prompt as 'xwin jwm', any error message should give clues to what is missing. I shall be testing tomorrow AM, my time.

EDIT: Just found I can't install a pet on slackbones64. Have to work that out first, for some reason I expected that package in all puppy's.

Please read the note at the top if the first message (dated 7 may) for some important information.

There are quite a few changes and improvements between what your current one is and the new one, so it could be well worth scanning the few pages of the thread before installing.

Any reports relating to JWM and the build should go in the JWM thread with a title including '64bit' so I know which build I'm dealing with. Also Joe monitors and ocassionally answers in the thread,

Hopefully a X86_64 jwmconfig2 will appear soon to match your systems.

P.N. This was built on and initially tested on fatdog64 v620, I have yet to test it on slackbones64, so there may be other packages required to deal with dependancies, at the least it should start from a prompt as 'xwin jwm', any error message should give clues to what is missing. I shall be testing tomorrow AM, my time.

EDIT: Just found I can't install a pet on slackbones64. Have to work that out first, for some reason I expected that package in all puppy's.

regards
scsijon

Yes, PETS will not install natively. That was an intentional decision during the design process. The reason we did this was to prevent the possibility of someone taking some arbitrary PET they found and trying to install it. There are Pets from the 4.x series, that are still floating around and people are finding with google.
Obviously someone with knowledge can extract the files from the pet and manually install the files into the file system. But If you can do that... you probably can compile it from source easy enough or find a slackware package for that program.

Progress on v2.0 is coming along, still a bit away though. Got a few bugs to work out.

I have started to have a play with: slackbones-v1.2-x86_64.iso
and i would like to build the graphics driver amd-driver-installer-catalyst-13.1-legacy-linux-x86.x86_64.run
but i am having a really hard time doing so.

It fails with a message telling me that it could not find a version.h file, and that certain tools are missing,
but it does not mention what these tools are.

Any help/guidance would be much appreciated. (or an actual package that i could install)

I have started to have a play with: slackbones-v1.2-x86_64.iso
and i would like to build the graphics driver amd-driver-installer-catalyst-13.1-legacy-linux-x86.x86_64.run
but i am having a really hard time doing so.

It fails with a message telling me that it could not find a version.h file, and that certain tools are missing,
but it does not mention what these tools are.

Any help/guidance would be much appreciated. (or an actual package that i could install)

CatDude
.

I dont have any ATI hardware so I cant build the drivers myself and test them. What you could do is install strace from the slackware repo and have that output to a file when you run the ATI run file. Then post that and I may be able to find out what's not being found.
I'd need to know what tools are missing to be able to provide them for you.

I dont know how current ATI installers work, but I thought it would save a file somewhere with a report of the installation or the failed installation. It's gotta record stuff somewhere. Otherwise there's no way to debug what errors you have.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum