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

[saintless]

Thanks for testing this, William.

I will remove firehol then and add puppy-firewall not active from boot as it is in Puppy. It is much easier to be setup and well known to Puppy linux users. I'm sure I can make latest Firehol work on DebianDog but it is not easy to set it up as puppy-firewall. Advanced user can install anything from debian repository later and remove puppy-firewall.

Toni

[fredx181]

Hi Toni,

No, I rename manually infonew to info-new before running restdpkg, otherwise I get error message from terminal restdpkg can't find info-new folder.

Ah, I see, mysterious why it didn't work for you but we'll see later.

exit 0
For example if some program like puppy firewall adds information there at the end it is after "exit 0" line and does not read the information after "exit 0". Do you see any problem in removing this line?

I don't know.
In rc.local it says explicitly "#Make sure that the script will "exit 0" on success or any other value on error."
Maybe this is useful:

Code: Select all

line="new line before exit 0"
sed -i '$ i '"$line"'' /etc/rc.local

It will insert a new line just before "exit 0"

Or make init script specially for firewall in /etc/init.d
If you want I can help with that.

Fred

[saintless]

In rc.local it says explicitly "#Make sure that the script will "exit 0" on success or any other value on error."
Maybe this is useful:

Code: Select all

line="new line before exit 0"
sed -i '$ i '"$line"'' /etc/rc.local

It will insert a new line just before "exit 0"

Or make init script specially for firewall in /etc/init.d
If you want I can help with that.

Yes, I read the same about exit 0 line. It is better to keep it inside rc.local to be safe.

I will try to edit firewall script and ask for help if I can't. It will be nice experience for me

Edit: Quick test shows it is possible to have puppy-firewall working as multiuser with different firewall settings for each account. I need to test this proper and check out for errors but it should work.

Toni

[anikin]

Hi Toni and everyone,

Regatding firewalls, firstly, you're not required, or even expected to provide firewalls or firewalling guidance to users. That is simply not your job. By anaology, you gave the customer a car and it's entirely his responsibility how to drive it - safely by the rules of the road, by his own rules, or without any rules. Secondly, why is the choice limited to only two options - firehol vs puppy firewall? In my humble view, if DebianDog has to have a firewall, the choice should be uwf vs arno-iptables-firewall. Both are simple and easy to understand and use, both are installable via apt-get, besides uwf is the default firewall in Ubuntu. Everyone knows, what's good for Ubuntu is good for Linux and this community Let's test these options too before making the final decision. As a side note, the installation process of arno-iptables-firewall will teach the user almost everything he needs to know about firewalling. However, ufw is simpler and it's really hard to chose between the two - both are excellent.

[fredx181]

Hi Toni,
First, here's new mountlink script, I tested a lot with all sort of cases and should be ok now.
Also, not sure if it's useful, a graphical sudo script: "gsudo".
It's similar to gsu but then for sudo so needs user password.
See attached zip.

Second..., I couldn't resist to try restdpkg on Jwm version and got the same broken dpkg, same as you had.
So that made me think about what's the difference then between openbox and jwm version.
I found out:
It' because of the residual config files from some packages that are still left on the jwm version.
What I did (on JWM version) -before installing and running remastercow- was this:

Code: Select all

dpkg --purge `dpkg --get-selections | grep deinstall | cut -f1`

This removes the config files and the registration of these packages.
Then install and run remastercow exactly the way you described with audacity and vlc.
Ok then reboot with empty (or without) savefile and do again:

Code: Select all

dpkg --purge `dpkg --get-selections | grep deinstall | cut -f1`

Load the modules, run restdpkg and it's all fine then.
I'm not sure yet but maybe it's sufficient to put the dpkg --purge line on top of remastercow and restdpkg.
And it's good I think to remove the config files for new iso.

Fred

[saintless]

First, here's new mountlink script, I tested a lot with all sort of cases and should be ok now.
Also, not sure if it's useful, a graphical sudo script: "gsudo".
It's similar to gsu but then for sudo so needs user password.

Thanks, Fred, I will include gsudo and use it in future versions.

And it's good I think to remove the config files for new iso.

I will do that. I don't know much about config dpkg files but it is great news you found this and it is easy to fix it. I will continue restdpkg tests with remastered version without config files then.

Toni

[saintless]

As a side note, the installation process of arno-iptables-firewall will teach the user almost everything he needs to know about firewalling. However, ufw is simpler and it's really hard to chose between the two - both are excellent.

Thanks, Anikin.
I will test ufw and arno-iptables-firewall to see how easy will be for me to setup both. But again I also start to think firewall should be user choice and not included by default. I will make proper deb package with puppy-firewall available for download for quick and easy setup. It is well known to puppy linux community and really easy to set it up from non experienced users. It will be good to have it as option.

Toni

[fredx181]

Hi Toni,

I don't know much about config dpkg files

In synaptic:

Fred

[fredx181]

Hi Toni,

I'm not sure yet but maybe it's sufficient to put the dpkg --purge line on top of remastercow and restdpkg.

Tested this now and it works well to put this at the top (just under the gsu line) in remastercow and restdpkg:

Code: Select all

dpkg --purge `dpkg --get-selections | grep deinstall | cut -f1` 2> /dev/null

Added "2> /dev/null" to suppress error message if there aren't any residual config files from packages.

Fred

[saintless]

Tested this now and it works well to put this at the top (just under the gsu line) in remastercow and restdpkg:

Hi, Fred. I'm remastering after running this command. New JWM version will not include config files for not installed packages. Do we still need to add this line in RemasterCow in this case?

Toni

[fredx181]

Hi Toni,

Do we still need to add this line in RemasterCow in this case?

Yes, better do because when a user makes a remaster after removing (instead of purging) packages like:

Code: Select all

apt-get remove <packages>

there are again left residual config files which will conflict with the processing by restdpkg.

Btw, Here's the live.cfg I made:

Code: Select all

label DebianDog live-boot v2 in RAM live persistent
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live persistent config swapon noprompt quickreboot autologin toram=01-filesystem.squashfs

label DebianDog live-boot v2 live (no save)
kernel /live/vmlinuz1
append initrd=/live/initrd1.img boot=live config swapon noprompt quickreboot autologin

label DebianDog Porteus in RAM changes=/changes.dat
kernel /live/vmlinuz1
append initrd=/live/initrd1.xz noauto from=/ copy2ram changes=/changes.dat

label DebianDog Porteus Always Fresh
kernel /live/vmlinuz1
append initrd=/live/initrd1.xz from=/ nomagic base_only norootcopy

label DebianDog live-boot v3 in RAM live persistence
kernel /live/vmlinuz1
append initrd=/live/initrd.img boot=live persistence config swapon noeject quickreboot autologin toram=01-filesystem.squashfs

label DebianDog live-boot v3 live (no save)
kernel /live/vmlinuz1
append initrd=/live/initrd.img boot=live config swapon noeject quickreboot autologin

For the width "menu width 70" is just enough in menu.cfg but if you want to add some more text to the label make it 80.

Fred

[saintless]

Hi, Fred.

I will add dpkg line in remastercow. Thanks for the menu.

Just for information - I'm in trouble again.
Remmeber blkid problems with dropdown menu and user account for remastering scripts? I thought your new ktsuss fixed it but now we need to remove $HOME lines from RemasterCow. New ktsuss cleans only /root folder and not /home/puppy when I run it from puppy account.
Also the old ktsuss makes possible to have separate firewall for every user account with firewall-puppy and the new ktsuss can't do this.
I will install again the older ktsuss package and remove the new one which brings back blkid command problem. I will fix it different way instead installing new ktsuss. Old ktsuss seems better choice for multiuser system.

Toni

[fredx181]

Just for information - I'm in trouble again. Smile

What! Again? Should I send you money? You are not on drugs I hope!

Almost every advantage brings a disadvantage, that's life, sigh...

I'll downgrade ktsuss also then.
Thanks for finding out.

Fred

[saintless]

You are not on drugs I hope!

I'm not sure my self anymore...

New and final version Firewall-Puppy edited for DebianDog:
http://smokey01.com/saintless/Fredx181/ ... 1_i386.deb
After installing the deb package start it from Settings -> Firewall Puppy
Different structure from the original.
rc.firewall is now created in $HOME/ and can be different for each user account.
/etc/init.d/firewall-puppy is the startup script and searches for $HOME/rc.firewall on boot (no /etc/rc.local entry anymore).

Testing is welcome.

Edit: One issue I just found is /home/puppy/rc.firewall is owned by root but Firewall-Puppy needs ktsuss or sudo for changing firewall settings so root ownership should not be a problem.

Edit2: Fixed owner for $HOME/rc.firewall and start firewall script moved to $HOME/Startup

Toni

[saintless]

First, here's new mountlink script, I tested a lot with all sort of cases and should be ok now.

I confirm it works with and without changes= boot option, Fred. I will test it more tomorrow.

Toni

[mcewanw]

In rc.local it says explicitly "#Make sure that the script will "exit 0" on success or any other value on error."
Maybe this is useful:

Code: Select all

line="new line before exit 0"
sed -i '$ i '"$line"'' /etc/rc.local

It will insert a new line just before "exit 0"

Or make init script specially for firewall in /etc/init.d
If you want I can help with that.

Yes, I read the same about exit 0 line. It is better to keep it inside rc.local to be safe.

Personally, I don't think exit 0 is necessary at all here, and could indeed be a nuisance in some circumstances. As far as I know, and this proves to be the case in testing, 0 is the default exit code for a script that has no error (by which is meant that the last command in the script executed successfully) on exit (error code can be shown after running script with echo $?). In fact, putting exit 0 at the end of the script does nothing at all to ensure that the rc.local exits with a 0 exit code if, for example, something causes an error in the script which causes it to exit prematurely. If there is an error generated, it surely should be exiting with a non-zero exit status? I think the warning comment is just to ensure people writing code in rc.local don't wrongly write exit non-zero number for bits of code that should be returning a non-zero exit code (for example, just having the line grep hello would normally result in a non-zero exit code).

I think some people are simply mistaking the meaning of that exit 0 warning message and thinking they must put exit 0 at the end of the script. In some distributions they do and in some they don't...

In googling, I haven't found any explanation why some say you need to put exit 0 at the end. Okay, can play 'safe', but I can't see why.

Note that because rc.local begins with #!/bin/sh -e, the -e means (I think) the script will terminate on there being any non-zero error code generated, so if you want the script to continue for non-zero exit commands within the script you can add || true to the end of any such commands. But I still don't think and exit 0 is required at the end of the script...

[saintless]

...Okay, can play 'safe', but I can't see why. ...

Hi, William.

Maybe some programs installed with apt-get add lines in /etc/rc.local
This new lines have to be added before "exit 0" and with sure this programs depend on "exit 0" line and most probably will give error message if it is missing.
It is better to keep the system compatible with debian packages instead breaking debian compatibility in favor of other distro packages.

Toni

[mcewanw]

Hi William,
Finally took the time to do some mplayer testing now.
I just tested different mplayer versions using the command line (mplayer) with same movie everytime (360p) only on openbox version.
First, included mplayer (from default installed gnome-mplayer) uses around 20% cpu.
Then uninstalled (gnome-)mplayer) and installed mplayer from debian-mutimedia, result is the same, around 20% cpu.
Installed mplayer2 , result is the same, around 20% cpu.
Uninstalled everything related to mplayer and installed the gmplayer from DebianDog_Jwm: result: double cpu usage (around 40).
Uninstalled it and tried the other gmplayer you once found (gmplayer_1.1): result: double cpu usage.

So it seems to me that the gmplayer versions use a lot more cpu.

Fred

Hi Toni,

Following Fred's confirmation of my earlier testing (which I have double-checked just now with same results) I strongly advise replacing current gmplayer in next iso release with Fred's gnome-mplayer package despite the uncompressed size increase of around 12MBytes.

[saintless]

Hi, William.

Something to concider before making such replacement:

1. Which one is the package you mean? This one:
http://smokey01.com/saintless/Fredx181/ ... -1.0.4.deb
Or this one:
http://smokey01.com/saintless/Fredx181/gmplayer_1.1.deb

2. Both packages will add around 30 non-debian-wheezy libs in /usr/local/bin. Something I try to keep at minimum and only in /opt/lib We have only 3 non-wheezy libs now.

3. Do we still need flac installed if we change gmplayer?

4. Is everything still woring the same way regarding xhippo --> mplayer or we need some configuration changes (I mean xhippo plays flac for example and gmlayer does not. New gnome-mplayer will play flac files. If we remove flac we need to configure the system to play flac with gnome-mplayer for user and root and skel).

5. In next DebianDog gmplayer will be uninstallable with:

Code: Select all

apt-get purge gmplayer-portable

And installable again with this package:
http://smokey01.com/saintless/Fredx181/ ... 6_i386.deb
Very easy to change the package any time.

6. Is there anything else than CPU test result that makes gnome-mplayer better alternative considering the above points?

Toni

[mcewanw]

Hi Toni,

xhippo will be fine using any mplayer. As you say though, if you remove flac, xhippo would need told to use mplayer for flac playing instead of flac decoder, but you could leave flac in since it is an encoder as well as a decoder if you wanted.

EDIT: Just checked, and xhippo setup is fine whatever happens. I already coded the current backend player of xhippo (xhplay) to use mplayer part of gnome-mplayer for flac if the flac encoder/decoder wasn't installed (though I think it is good to leave flac installed anyway). So wouldn't need any changes to /etc/skel.

Sorry, I hadn't thought about the extra libs in gnome-mplayer being non-Debian.

I take your point about easily being able to remove the current mplayer, if wished. Because of the non-Debian libs I think it is best just to keep old mplayer for the moment. Maybe find a Debian lib based solution later.

William