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

[saintless]

http://forum.puppyrus.org/index.php/topic,15557.0.html

Привет и большое

[saintless]

Hi, all.

I'm making some changes on the site. Created new DebianDog folder where the Beta iso will be placed later.
http://smokey01.com/saintless/DebianDog/
Two subfolders System-modules and extra-modules

System-modules content:
http://smokey01.com/saintless/DebianDog/System-modules/
00-locale-files.squashfs - 22Mb. - all /usr/share/locale files included. I think there is no need to create separate archives from each folder since single click on the module will open the content in new window with easy copy/paste option for any language folder in the system for remastering with only needed locales included.
.
00-man-doc-info.squashfs -29 Mb. - all /usr/share/man-doc-info files in case someone needs them.

02-wheeze-boot-folder.squashfs - /boot folder with kernel and initrd modules for 3.2.0-4-486 and 3.2.0-4-686-pae.

Separate kernel modules available for user remaster:

021-kernel-486.zip - default included in DebianDog. Available for download in case it is needed for remaster tests and test with other live linux as puppy.

022-kernel-686-pae.zip - Pae debian kernel

023-kernel-porteus-3.9.11.zip - Porteus kernel from first Porteus wheezy with option to add dpkg database information. Eventualy it will have problems to make linux-headers work but I think it is good to have it.

All we need is to extract the archives in /live and to change the boot code to point the correct initrd and vmlinuz and reboot.
All kernel modules have /opt/bin/script to update dpkg database if needed. Single click on the script does the job.

Remastering with new kernel process - boot with the new kernel and apt-get purge the default 486 kernel to save space. remove the previous vmlinuz and initrd from /live. Use RemasterDog to make DebianDog different kernel version and new iso.

06-DEVX-DebDog-2.squashfs - Devx compile programs module.

Initrd files for different save file options:

initrd-3.2.0-4-486-linux-live.xz - for linix-live boot similar to Porteus boot with similar save file options made by Fred.

initrd1-live-boot-v3-3.2.0-4-486.img - original Debian Wheezy initrd created with live-boot v.3

initrd2-live-boot-v3-3.2.0-4-686-Pae.img - original Debian Wheezy initrd created with live-boot v.3

Extra-modules folder for extra sfs modules:
051-smo-freeoffice.squashfs - SoftMakerOffice-FreeOffice - needs free registration with e-mail to use it.
More to be added later.

We keep Fredx181 folder for deb packages and other files related to DebianDog and Porteus-Wheezy:
http://smokey01.com/saintless/Fredx181/
Some cleaning and editing of the packages there is needed. I found gnumeric.sfs does not have working executable link for example. It will be fixed in time.

Fred,
if you like to have something different structured in Porteus-Wheezy folder just write what is needed.

Toni

[fredx181]

Hi Toni
It didn't happen overnight but now we got something!

Uploaded DebianDog-PorteusDog-test2.iso - 107 Mb.
http://smokey01.com/saintless/Light-Whe ... -test2.iso

Just a few minor issues to solve and the beta is ready I think.
What we didn't think of (well, at least I didn't) is the fact that it can't be installed on a FAT partition because of the symlink in the base folder for porteus boot (symlinks not supported by FAT).
I'll see if I can come up for an idea about that, at least the user should be warned about it.

Installed some programs and menu updates fine, with icons, great job by Terry!

The installer from Terry looks promising and IMHO it's a must to include.

So many things to test, I tested of course if porteus-boot-method works with the saving and all, it's fine except for the makepfile.sh script, it is not updated with progress bar (see below for new one, remove dummy .tar extension).

One unexpected thing for me was:
When activating some module there should be no traces left when you deactivate it.
But there are; in the menu, because of the mk.jwm generating I think.
Refresh-menus from menu made them disappear though.
Maybe it's me but I have same problem as William described about Wallpapers; stretch doesn't work, tested it with 06.jpg and still see bars on left and right (I have normal monitor, not wide-screen).

I like your decision for autologin as default on coming beta.
I'll test some more in next few days.

Fred

[fredx181]

Hi Toni

Fred,
if you like to have something different structured in Porteus-Wheezy folder just write what is needed.

Yes, good idea, something like 'packages-porteus-wheezy' maybe for e.g. special xfce, openbox or whatever packages.
Coming more I expect but here's one:(see attached, remove dummy .tar)

About fsck for porteus-boot you asked:
Savefile will always be checked by default.
For all partitions to check there's boot parameter 'fsck'

Fred

[saintless]

Hi, Fred.
New folder for Porteus-Wheezy apps only:
http://smokey01.com/saintless/Porteus-W ... us-Wheezy/
I will also test mostly in the next few days and then I will add all fixes we find.

Toni

[fredx181]

Hi, Fred.
New folder for Porteus-Wheezy apps only:
http://smokey01.com/saintless/Porteus-W ... us-Wheezy/
I will also test mostly in the next few days and then I will add all fixes we find.

Toni

Thanks Toni, that was fast.
Nice organizing of the site btw!

Fred

[mcewanw]

Maybe it's me but I have same problem as William described about Wallpapers; stretch doesn't work, tested it with 06.jpg and still see bars on left and right (I have normal monitor, not wide-screen).

Fred, this is how saintless explained the method to me (though I haven't tried it):

Terry is right and GUI option to use Stretch is working. Here is how to do it. I also did not notice it works this way till now.
Open Wallpapers GUI and remove all pictures from Remove button. Then set Stretch and add first pictire. It will be set to stretch. Add the rest as Stretch this way or choose Scale, Tile, Center for each one before adding the picture with Add button.

I see the wallpapers are now activated by default with 'Stretch'.

Since this issue keeps cropping up, it may be that the method to change between Stretch, Scale etc is non-intuitive to the user, so perhaps that needs to be looked at. Best would be if the pictures didn't all need to be removed first, so that when user chooses mode (Stretch, Scale etc) from the drop down list and clicks Apply is all just happens. I think most people won't think of having to remove all the pictures first, then select mode and then re-add the pictures; that is unexpected procedure. It is not an urgent thing to consider for the beta iso release though, if it does all work as it currently is.

[sunburnt]

Guys; I setup Wallpapers to show the wallpaper`s "mode" at left side in the selected list.
If a wallpaper has the correct mode then there`s no need to remove it.
A Wallpaper and it`s mode must be selected before the Add button is clicked.
It does not matter if mode or wallpaper is picked first. The selected list shows what you got.
To change a wallpaper`s mode, you must remove it and add it again, of course.
With the add, remove, up, and down buttons, the list can be edited completely as is.
Apply reads the selected list & writes the file directly from the list box ( they look identical ).
# Again, Stretched distorts, if pic`s aspect ratio is close to the screen`s, then it looks okay.
For pics not close to the screen ratio, mtPaint can crop the pic so it`s close, then Stretch.
Like some of my girlie pics were 1440x968, so I cropped off the non-girlie side to 1200x968.


Toni; I`ll try the copy command, I think you`re right ( as usual...). It worked in Vterm though...
I`ll do more test with Grub4Dos. I`ve used SysLinux and ExtLinux before too, with good luck.

I was thinking of boot options in a "Text gui panel" making them "user friendly".

It looks like the Porteus folks think as I do, it seems to have most of what I`ve talked about.
# I think the next version of Debian Live may have some of the things I`ve discussed.


William; I read it and many others, but as I said, only the Puppy help described anything.
# There should be a law that full and complete descriptions are required, no hiding stuff...
.

[mcewanw]

### HELP... I`m stuck on grub4dos. Nothing explains what`s really going on.

bootlace - does not work with ext4
weesetup need
http://forum.puppyrus.org/index.php/topic,15557.0.html

Terry, looks like Puppy Linux maybe uses some kind of workaround for booting from ext4 using grub4dos but mikeb in the link below unfortunately can't remember what:

http://www.murga-linux.com/puppy/viewto ... 509#728509

It's the grub4dos mbr which can't load grldr from an ext4 partition apparently. It isn't clear to me if shinobar is suggesting that the following grub4dos version will boot from ext4 (reads like that):

http://www.murga-linux.com/puppy/viewto ... 995#384995

I guess this is the grub4dos Puppy (shinobar's grub4dosconfig) instructions you referred to already:

http://shino.pos.to/linux/puppy/grub4dosconfig.html

Here is a 2010 post about ext4 issues; includes info about using 'wee' MBR:

http://code.google.com/p/grub4dos-chena ... etail?id=3

I think shinobar's grub4dosconfig uses that 'wee' mbr so should work loading grldr from ext4 partition.

IMPORTANT: Note that ext4 is now recommended if using usb flash drives since it contains several performance improvements compared to ext2, BUT it is important that you turn of ext4 journalling to prevent excessive usb flash writing, which would otherwise shorten its life. To turn off ext4 journaling you just use:

Code: Select all

sudo mkfs.ext4 -O ^has_journal /dev/xxxx

(or some variation of that such as sudo mkfs -t ext4 -O ^has_journal ... or sudo mke2fs -t ext4 -O ^has_journal ...)

I suggest using sudo above since normal user may wish to install to usb.
-----

As I've discussed earlier, it is also important to consider erase block alignment issues to speed up usb flash writing in particular:

http://www.thomas-krenn.com/en/wiki/Partition_Alignment

anikin pointed me to a radical (but somewhat complicated) approach to ensuring optimum alignment:

http://murga-linux.com/puppy/viewtopic. ... 958#766958

However, it seems from my reading that modern linux partitioning tools do a reasonable job at it nowadays (I'm not sure). Still good to have a quick read of the above thomas-kern link so you no what to check for.

[sunburnt]

Thanks William; Looking at the info. you`ve posted. I`m going to have to let this soak in.
Parted wants to start at 1 MB, but blogofterje shows an even better performance setup.

# Grub2 is looking like a good choice as it will boot ext4. But I`ll try to get info. on wee.
It`s good you pointed out the ext4 USB advantage, I hadn`t heard ext4 improved much over ext3.
If that`s the case, then ext4 for O.S. and persistence parts. on all media: HD, Flash, SD, and MMC.
Still the option for a first FAT32 part. for Weeners compatibility, but no O.S. or persistence on it.
The only other option is to use the existing partition, so I should say something about performance.
Also tell about swaps, a swap part. or file on a HD will be used. Else use another cheap USB.
# I think at this point a Help button with a popup dialog is the way to go.


Toni; If you have time, explain what`s needed to make mk-menu do localizations.

# Also vovchik has told me I don`t leave enough room for foreign languages on my guis.
# Do you guys have any feed back on this.? ### And how to localize my gui apps...
.

[saintless]

Toni; If you have time, explain what`s needed to make mk-menu do localizations..

I don't know what is needed, Terry, but I will try to find out.

Toni

[fredx181]

# Grub2 is looking like a good choice as it will boot ext4. But I`ll try to get info. on wee.

Hi Terry
I've done some searching on wee and put together a little script "weeinst"
It's in the attached zip.

Code: Select all

weeinst /dev/sdb

for example will put the MBR in sdb.
Note that the included wee.mbr needs to be in /opt/bin
No needfor bootlace.com
After installing MBR , only grldr and menu.lst are needed.
Fred

[sfs]

new porteus-boot savefile-create

make-changes - of Porteus (en,ru gettext)
create-save-pfs - only russian, ntf
.pfs ~ .sfs

[mcewanw]

Thanks William; Looking at the info. you`ve posted. I`m going to have to let this soak in.
Parted wants to start at 1 MB, but blogofterje shows an even better performance setup.

# Grub2 is looking like a good choice as it will boot ext4. But I`ll try to get info. on wee.
...
### And how to localize my gui apps...
.

I think starting at 1MB boundary probably aligns things quite well and is good enough for our purposes. If someone wants to preformat some other scheme (e.g. per blogofterje) we just don't want to overwrite that. I'm not sure about Grub2 - I had a look into it (since my netbook Lubuntu install uses that) Grub2 seems pretty big and complicated - grub4dos is relatively small, easy, and seems to work well.

As for localising apps - I use gettext in xrecord, which is the preferred practice I believe. L18L is the guy who handles most of the details of that in Puppy and he helped me out in the past with how to do it; it's easy to add to normal apps. Don't know how it fits in with the menu writing though.

[saintless]

new porteus-boot savefile-create

make-changes - of Porteus (en,ru gettext)
create-save-pfs - only russian, ntf
.pfs ~ .sfs

Thank you, Sfs!
This download link does not work:
http://cdn.2safe.com/661292033760/make-changes.tar.bz2
I will look for make-changes in PRA iso.

Fred, unfortunately only in Russian but if you like to test PRA here is download link:
http://sourceforge.net/projects/puppyrusa/
For frugal install copy all the content of the iso in /pra folder (as example for the boot code) and use this code:

Code: Select all

title PuppyRus-A
root=(hd0,0) 
kernel (hd0,0)/pra/pra/vmlinuz-3.13.5-pf dir=/pra/pra  quiet
initrd (hd0,0)/pra/pra/initrd.xz

I'm happy i can use it in Russian

Toni

[saintless]

Toni; If you have time, explain what`s needed to make mk-menu do localizations..

Hi, Terry.
made trials today and here is how I see the option for localization mk-jwm.menu. No need to rush on this because we still are testing and any changes in mk-jwm.menu now without proper testing are not good idea.

After installing locales package and choosing different locales new file appear: /etc/default/locale
I will give bulgarian language as example and the content of /etc/default/locale will be:

Code: Select all

#  File generated by update-locale
LANG=bg_BG

mk-jwm.menu should chek if there is /etc/default/locale file and read its content. If LANG=bg is taken as base for .desktop file reading debmenu2desktop.convert should read Name[bg]=5=846J@ =0 ?0:5B8 (Synaptic) inside desktop file. if there is no Name[bg]= inside desktop file then read Name=
This will make localization af programs names inside start menu. Something that Debian menu system does not support reading /usr/share/menu files.

Localization of root menu categories is more difficult I think. Debian menu uses language and encoding functions in /etc/menu-methods/menu.h; jwm; icewm-common while reading /etc/menu-methods/lang.h
We can not use anything from this method.

What we can do is to make separate menu-root.lst files with corresponding categories.lst translations for every language and to change them based on the information in /etc/default/locale
Or to make only separate root-menu.lst for each language and to use in the beginning of menu-puppy change to default root-menu while translating categories.lst with new installed or removed package and at the end of menu-puppy to copy back root-menu.lst for locale language. The same dirty fix as Fred's one changing link to bash/dash for Frisbee at the beginning.

Or in my oppinion not to make root-menu localization at all for mk-jwm.menu. It looks confusing for me at least to read root-menu in my native language.

Toni

[sunburnt]

Toni; A very good explanation of what`s going on, thank you.
Yes, literal translations only work for discrete words, but the meaning is the important thing.

I`m thinking this... Few desktop files are localized, so localizing them must be automated.
The desktop file concept is fairly good. but it`s so poorly supported, as localizing is difficult.
Example: How do you write Audacious in Bulgarian language text.? It`s meaning gets lost...

I put forth the idea of a key in desktop files setting user group type to control the menus.
A key to control each user would be overkill I think. So Group=(group) is used for control.
Most apps are common, so only original desktop file`s needed to show for all. No Group=.
# Also then main menu desktop files, key "Main=true" and Group=. So no menu-root.lst file.
If no Group= or Root= keys in the desktop file, then it`s a common app and shows for all.
If there is a Main=true key but no Group= , then it`s a main menu item that shows for all.
# This setup makes desktop files control all of the aspects of the menu except Categories.

# Don`t get worried, this is just thinking about solutions for desktop file fixing.
.

[sunburnt]

Toni; It sounds like the Debian menu does localizations well, right.?

And the Debian menu is well setup now, shouldn`t it be default.?
But there may be other reasons to not use it for default menu.

[mcewanw]

Toni; It sounds like the Debian menu does localizations well, right.?

And the Debian menu is well setup now, shouldn`t it be default.?
But there may be other reasons to not use it for default menu.

The main reason not to use it as default is that it is ugly compared to the one your code creates Terry, and that is a very good reason not to use Debian menu system as default! Users should be given the nicest menu we have by default. The default distribution itself is released in English anyway, so users can choose Debian menu system then if they so want.

[saintless]

Hi, Terry.

I see no problem Debian menu to be the default one but since your mk-jwm.menu is working really well in the last test iso I think we should keep it as default menu. It looks easier to navigate and has different icons for root menu.
We have easy switch command (menu-debian) to get back debian menu and locale files are not included in DebianDpg iso. We have them as separate sfs module for download.

I attach pictures for debian menu on English and Bulgarian. Personaly I will never use it in Bulgarian. Looks confusing to me.

Toni