Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

[mcewanw]

Live-snapshot I didn't include because I think it needs more testing and also I'm not sure if it is a useful addition, we have porteus-boot with save on exit supporting file deletion which live-snapshot doesn't AFAIK.

Fred

I think it should be included, though I don't think it should have a menu item if the boot method is not the usual one for the particular debiandog (in this case openbox version). Afterall, the size is tiny, and there may well be some users who will prefer the alternative boot strategies, and these flexible alternative boot strategies are core concepts underlying all debiandog developments so far - it would be a pity to diverge from that since ultimately the strength of this project stems from its collaborative development effort.

Otherwise, you encourage forks and derivatives, which is fine but can be confusing and water down the development effort since it ends up being spread amongst the derivatives and individually tailored forks - becomes then difficult to keep track of any potential improvements/fixes that have been implemented in other derivatives.

There will always be forks and derivatives (even if just loose ones) because some will want to change some things and go it alone, but surest development, I feel, lies in collaborative core rather than individual choice. However, that is different from development decisions by committee or forum, which is too loose since casual users often haven't familiarised themselves with all the development issues.

Of course, DebianDog itself, to a large extent is 'just' a derivative of Debian live, but it is a particularly tailored one, taking as it does ideas from Puppy, Porteus and so on, to produce quite an individual flavour.

Personally, I'm happy xhippo, with its front and backend scripts, continues to be used in core because it provides a relatively tiny multimedia system (which could be adjusted to use, for example, mplayer or vlc underneath). Being tiny it doesn't really cost anything to include it, whether a user decides to install/use some other multimedia system altogether or not (and the sfs activation tools makes that even easier). If something smaller, but better or more flexible comes along, then of course that should be adopted - but it is good to have a stable and consistent core in all debiandog releases IMO.

[mcewanw]

Puppy is a great system, but it has long been known that it has two particular weaknesses, which were both the result of early development decisions.

1. It was developed as root user only, which is a pity, because the extra effort involved in keeping any Linux system multiuser is worth investing in. Certainly, it made it easy to write simple apps and programs for Puppy since there were never issues concerning not having sufficient access rights or permissions to underlying system utilities or storage areas - no sudoers rights to be concerned with and so on. But that encouraged program creation which were not easily ported to other Linux systems and, as was later discovered at cost - some applications don't like to be run as root. Now that a new wave of Puppy is being developed, making it multiuser should be a priority with that hindsight.

2. The other well-known problem has been package management issues, particularly issues concerning poor ability to track and resolve dependencies. One way out of that is to use an established repository system and tools, such as dpkg, but I'm not myself against Puppy using its own repository and tools since they can be specially tailored for small size. I do note, however, that the largest push in Puppy developement isn't so far away from DebianDog in terms of its movement - albeit involving build system Woof. I imagine that some of the developments documented in this thread will be read and found useful in these Puppy developments - all distributions are ultimately collaborative, whether acknowledged or not.

[mcewanw]

SFR has pointed out a bug that effects both xrecond and pavrecord. It's an old re-surfaced issue, first discussed on this forum in 2009, that seemed to depend on arecord version. I'll work on that today if I find time and post updated versions, so maybe best to hold back on next iso release till that fix posted.

Cheers, William

[saintless]

I had to run 'Diagnostics' on Frisbee before wlan would show any networks ... in case someone else has the same issue.

Thank you, wireless test reports are something we do not get often.

[saintless]

Hi, William.

I think it should be included, though I don't think it should have a menu item if the boot method is not the usual one for the particular debiandog (in this case openbox version).

Menu entry is proper at least for Jwm version at the moment. Live-snapshot default setup makes snapshot from /live/cow (but it can be changed to $HOME/ or different directory). In Jwm version we have /live/cow by default for live-boot-2x and porteus-boot + cow-nosave, cow-savefile, cow-savepart scripts that will create /live/cow for live-boot-3x with single click (this will give option also to use RemasterCow with live-boot-3x and it was not possible with previous iso).
In general you can use Utility - Snapshot Make (or live-snapshot) to create snapshot with changes from all boot methods. But you can load this snapshot on boot only with live-boot-2x. The program has warning it should be used with live-boot-2x.

SFR has pointed out a bug that effects both xrecond and pavrecord. It's an old re-surfaced issue, first discussed on this forum in 2009, that seemed to depend on arecord version. I'll work on that today if I find time and post updated versions, so maybe best to hold back on next iso release till that fix posted.

I guess you mean next iso for future one, because yesterday both iso versions were replaced with newer.
We will include the fixes as deb package or files to replace for next version. I'm not sure yet what we should add more for next version.
I will try to explore better Russian sfs-linux work to see if I can adapt something more than live-snapshot for DebianDog.

Toni

[mcewanw]

SFR has pointed out a bug that effects both xrecond and pavrecord. It's an old re-surfaced issue, first discussed on this forum in 2009, that seemed to depend on arecord version. I'll work on that today if I find time and post updated versions, so maybe best to hold back on next iso release till that fix posted.

I guess you mean next iso for future one, because yesterday both iso versions were replaced with newer.

Ah, okay, that's a pity. Pavrecord and also xrecord just needed a quick fix to one line of the script. It is a relatively important fix though, without which using provided arecord vu meter can cause later problems with some apps when running as user root. It's really a problem re-introduced with later arecord program vu display option. The method used in xrecord and pavrecord is commonly used according to google searches, and it used to be fine, but something has changed with arecord such that using that vu as root user will change /dev/null into a txt file - fixes itself on reboot, but clearly it needs addressed. I have a fix and another from forum member SFR (but that one didn't work for me yet and he hasn't yet responded to my PM, but as I say, the fix I have seems fine).

Cheers, William

[stemsee]

One way out of that is to use an established repository system and tools, such as dpkg, but I'm not myself against Puppy using its own repository and tools since they can be specially tailored for small size. I do note, however, that the largest push in Puppy developement isn't so far away from DebianDog in terms of its movement - albeit involving build system Woof. I imagine that some of the developments documented in this thread will be read and found useful in these Puppy developments - all distributions are ultimately collaborative, whether acknowledged or not.

Which came first the chicken or the egg?

full dpkg is active in 'woof-next', as well as hotplugging enabled by default, Indeed puppy-next-generation (ng) is adjusting puppy to fit the host rather than as previously squeezing the host into puppy. The initrd system with modules.sfs (zdrv) is able to boot DebianDog without issues, and should be added as the 5th boot method (Why? because of kernel-kit-ng=roll your own(easily)), at tow (time of writing) only the 01-filesystem.squashfs needs to be copied/renamed to puppy.sfs in the live folder, both systems residing in live without interference. In fact I see an opportunity in this. It should be possible to specify the name of the sfs/squashfs main-file to load as a kernel argument rather than only fom initrd/DISTRO_SPECS . I agree that multi-user should be default, though i have no use for it myself, unless I wanted to setup multi-seat as in C3Sl from Brazil = hassle as comparred to xinput pseudo multi-seat.

It is great for me and all users to have two related systems that fit on the same usb stick, each providing a somewhat different feel and experience. I am used to puppy and slowly finding my way around DebianDog, I still haven't memorized the three boot methods (or 4), puppy now has two initrds/boot methods and also three save methods; save to partition, save to file, save to folder.

So for the user it is great to simply enjoy both the chicken and the egg without stressing over which arrived first! As long as they coexist peacefully and to the benefit of the broader community.

[saintless]

Hi, Stemsee.

The initrd system with modules.sfs (zdrv) is able to boot DebianDog without issues, and should be added as the 5th boot method (Why? because of kernel-kit-ng=roll your own(easily)), at tow (time of writing) only the 01-filesystem.squashfs needs to be copied/renamed to puppy.sfs in the live folder, both systems residing in live without interference. In fact I see an opportunity in this.

Any other advantage you see in such configuration?
I see many disadvantages regarding some apt-get programs compatibility with non debian kernel and I'm sure many debian options and puppy options will be lost or broken.
For example I doubt you can still load 3,4,5,6,7,8 modules on boot as DebianDog does now.
I also doubt you can use all Puppy save options unless all needed scripts are included inside initrd.
But testing iso will show all advantages and disadvantages of such configuration. Perhaps you can upload working iso with Puppy initrd and kernel and DebianDog module? I have doubts it will boot on my old hardware but I'm sure Fred or William will test it. Then we can make separate kernel+initrd module for testing and improvements from anyone interested to work on this.

[saintless]

For next version - wget-progress written from Sfs (sfslinux) for PuppyRus:
http://smokey01.com/saintless/Fredx181/ ... ogress.zip
Just extract in /opt/bin and type in terminal:

Code: Select all

wget-progress <download-file-location>

[saintless]

Hi, William.
Is there a way to change subtitle encoding from xhippo?
I can do it from gnome-mplayer but I see no such option in xhippo configuration file. Setting up subtitle encoding to CP1251 in gnome-mplayer before starting xhippo works only for gnome-mplayer.

Toni

[saintless]

Hi, Fred.
In case you like to check this:
http://smokey01.com/saintless/Fredx181/ ... ool.tar.gz
It is porteus xpns-tool for network setup hacked by Sfs.
It works for me as it is for wired network. It uses fixed dns server but I guess installing resolvconf package will make it auto detected.
Just purge frisbee, extract the files in /opt/bin and type xpns-tool in terminal to start the gui.
I know we have enough network managers but I'm checking what works on DebianDog without much changes.

Toni

[stemsee]

Saintless

Any other advantage you see in such configuration?
I see many disadvantages regarding some apt-get programs compatibility with non debian kernel and I'm sure many debian options and puppy options will be lost or broken.
For example I doubt you can still load 3,4,5,6,7,8 modules on boot as DebianDog does now.
I also doubt you can use all Puppy save options unless all needed scripts are included inside initrd.
But testing iso will show all advantages and disadvantages of such configuration. Perhaps you can upload working iso with Puppy initrd and kernel and DebianDog module? I have doubts it will boot on my old hardware but I'm sure Fred or William will test it. Then we can make separate kernel+initrd module for testing and improvements from anyone interested to work on this.

I will do. So I will prepare iso/s with pae and non-pae kernels.

[fredx181]

Hi Toni,

Hi, Fred.
In case you like to check this:
http://smokey01.com/saintless/Fredx181/ ... ool.tar.gz
It is porteus xpns-tool for network setup hacked by Sfs.

Tested with wireless and works well.
Not that user friendly as frisbee or SNS, for example the user needs to copy a file to make the wireless setting survive on reboot.

Some other things:
On Jwm version booting using live-boot the reboot and shutdown menu entries don't do anything when running as user puppy. (I think this was the case on previous releases also)
We forgot to add the gsu line on top of /usr/bin/frisbee.
I often do "sudo su" to have root rights on everything I do in that terminal session, on Jwm version I get:

Code: Select all

puppy@debian:~$ sudo su
[sudo] password for puppy: 
xauth:  timeout in locking authority file /home/puppy/.Xauthority
xauth: (argv):1:  unable to read any entries from file "(stdin)"

Not a big deal because after waiting some time it works ok.
Also the colored network down/up messages won't show when using puppy account, don't know why yet.

About Live-snapshot I come back on my decision not to include, I was to quick on deciding that and didn't know much about it (still need to study more).
Also I agree with William that it's good to include things -as much as possible- the same in both versions.

Fred

[stemsee]

Here is non-pae iso image, sporting kernel 3.15, I didn't delete modules from puppy.sfs (DebianDog 01-filesystem.squashfs). I booted on qemu (not recommended) I recommend copying files to hdd/usb aka frugal install and boot with puppy menu.list and puppy kernel arguments,

title DebianPup
root=(hd0,0)
kernel /live/vmlinuz pmedia=atahd psubdir=live pfix=fsck
initrd /live/initrd.gz

Could use puppy_savefile.4fs, essential debiandog modules can be merged to a adrv and ydrv, or zdrv.sfs all recognised by initrd (according to forum threads).

non-pae
https://drive.google.com/file/d/0B4GhZV ... edit?usp=1

pae 3.14.5
https://drive.google.com/file/d/0B4GhZV ... edit?usp=1

Please ignore the boot splash image from EmSee-2nd-Edition!! I'm too lazy to make another one now.

[mcewanw]

Hi, William.
Is there a way to change subtitle encoding from xhippo?
I can do it from gnome-mplayer but I see no such option in xhippo configuration file. Setting up subtitle encoding to CP1251 in gnome-mplayer before starting xhippo works only for gnome-mplayer.

Toni

I'm not sure what you mean Toni, since I've not tried that, but will! Can you set up subtitle encoding in mplayer rather than gnome-mplayer frontend?

William

EDIT: Ok, I've googled some links about this and will look into it.

EDIT2: Is this (below) what you are looking for Toni? I haven't tried it myself. xhippo has no control over the mplayer config (though xhplay could include extra mplayer subtitle related parameters, but that wouldn't be a good idea I think. Best just to prepare $HOME/.mplayer/config with requirements.

http://www.linuxquestions.org/questions ... es-604431/

Code: Select all

SOLVED for polish fonts with mplayer
edit the .mplayer/config file :

cat .mplayer/config
Code:

# Write your default config options here!

zoom=1

fontconfig = "1"
font = "dejavu sans"
subfont-text-scale = "3,3"
subcp = "cp1250"
sub-fuzziness = "2"

https://mplayerhq.hu/DOCS/tech/subcp.txt

[mcewanw]

Hi Toni,

Just trying out the new jwm debiandog. I selected Fred's Video2Audio-extract app from the menu in order to see if ffmpeg would download into an sfs correctly. It did. However, I can only activate/deactivate it from Xfe filemanager, which worked fine.

In Rox it shows up as a txt file now and hence no right-click activat/deactivate possibility; yet that used to work fine previously (or did I do something to make it work in last iso I wonder... but don't think so?). I note that some other sfs files do have right click activate though. Have you any ideo what the problem might be?

William

[saintless]

Hi, Fred.

On Jwm version booting using live-boot the reboot and shutdown menu entries don't do anything when running as user puppy. (I think this was the case on previous releases also)

Yes, it is like that. Pointing to separate script executing sudo did not work when I was trying to fix it but I have another idea to test.

I often do "sudo su" to have root rights on everything I do in that terminal session, on Jwm version I get:

Code: Select all

puppy@debian:~$ sudo su
[sudo] password for puppy: 
xauth:  timeout in locking authority file /home/puppy/.Xauthority
xauth: (argv):1:  unable to read any entries from file "(stdin)"

Not a big deal because after waiting some time it works ok.

Seems like something that needs fixing.

Toni

[saintless]

Just trying out the new jwm debiandog. I selected Fred's Video2Audio-extract app from the menu in order to see if ffmpeg would download into an sfs correctly. It did. However, I can only activate/deactivate it from Xfe filemanager, which worked fine.

In Rox it no longer shows up as a txt file now and hence no right-click activat/deactivate possibility; yet that used to work fine previously (or did I do something to make it work in last iso I wonder... but don't think so?). I note that some other sfs files do have right click activate though. Have you any ideo what the problem might be?

William

Hi, William.
Yes, something in Rox types about squashfs and sfs seems to be broken. It was working in the last version. I will look at it today.

[saintless]

http://www.linuxquestions.org/questions ... es-604431/

Code: Select all

zoom=1

fontconfig = "1"
font = "dejavu sans"
subfont-text-scale = "3,3"
subcp = "cp1251"
sub-fuzziness = "2"

https://mplayerhq.hu/DOCS/tech/subcp.txt

Unfortunately does not work for me, William. Mplayer does not even start with this config example but I will test more later. Removing zoom=1 does not help. I think we need to add some solution about this in HowTo thread.

[saintless]

Here is non-pae iso image...

Thank you, Stemsee.
Booting was not a problem but I can't find a way to use any kind of save file.
Creating puppy_savefile.4fs, 3.fs, 2.fs, renaming to puppysave.4fs, pupsave.4fs does not help. Keeping the save file in /live or at top of partition changes nothing.
adrv.sfs, ydrv.sfs, zdrv.sfs do not get loaded on boot.
The system does not have option to save changes at all this way.
If you have a solution for using puppy_savefile.4fs, please, post it.
Anyway it is a good base for testing and further fixing. I will pack kernels and initrd in separate modules with example boot code later.