Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 19 Dec 2018, 09:22
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Create Debian 9 (Stretch) minimal ISO similar to DebianDog
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 13 of 96 [1434 Posts]   Goto page: Previous 1, 2, 3, ..., 11, 12, 13, 14, 15, ..., 94, 95, 96 Next
Author Message
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Thu 10 Aug 2017, 15:02    Post subject:  

backi wrote:
Here is another practical tool for extracting a folder of debs. (for further converting).
http://smokey01.com/pemasu/pet_packages-exprimo/Extract-folder-of-debs-0.0.1.pet


Thanks, Backi. I just went back to the old trusted way I know: uextract, then terminal mksquashfs. I just get tired sometimes of having to bend my lazy butt out of the chair and start typing in the terminal to mksquashfs with parameters commands. Guess I'm not only getting old, but terribly lazy. Anyway, had a productive session here.....told myself that this XFCE I built cannot go over 280mb max without a major browser, and cannot go over 400mb max when a major browser sfs is loaded. The browser is firefox-45.9, and I made an SFS of it just an hr ago. This sfs sits in the frugal install XFCE folder waiting to be punched alive with SFS-Load GUI. Here's everything I've got included in this XFCE build:

-QtWeb 3.8.5 (build 108---mike's version on murga here, you cannot use qtweb from debian repos otherwise https will be non-functional)
-Redshift
-htop
-pupmd5sum
-conky everything + toggle.desktop control
-pulseaudio + pavucontrol (had problems with alsa & xfce)
-mtpaint
-themes package for xfce
-icons package for xfce
-uextract
-evince
-dog radio
-gnome player
-vlc player
-all of rcrsn51's scripts
-all of Fred's scripts
-claws email client
-gedit + leafpad
-about ~5mb of various libs needed for various things
-and then, finally, everything that xfce4 and xfce4-gooodies brings in, which is a lot

So when booted up frugally, I'm at ~280mb. When the firefox-45.9.sfs gets loaded, for heavy duty work (Youtube, etc), it all comes in at 396mb.....right under my limit. This build version is moving up into my top 3 or 4 rotation of all frugal installs on this 250GB external drive I use. And that is saying something since I keep up-to-date 21 frugal installs of various DDogs & many diff Pup versions. It's a little nuts, but I can think of worse hobbies----besides, I have melded (and got running stably) so many things from the puppy world into the DDog world that I think Dr. Frankenstein himself would be proud Twisted Evil

Now, my Frankenstein tendency is going to focus the rest of the evening on the budgie-desktop ddog build, most of it sitting lonely & neglected in its frugal folder. Booting to desktop is almost there, just have to make a few tweaks in the build-setup.
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Thu 10 Aug 2017, 16:26    Post subject:  

Hi all,

Just wanted to give a headsup for ddog-script builders, if you need a lightfast, blazing fast speadshet, puppy's dependable "mtcelledit" works like crazy. At less than 200kb install, for most simple spreadsheet purposes, you can't beat it.
puppy-mtcelledit-in-XFCE-ddog-build.png
 Description   
 Filesize   217.02 KB
 Viewed   582 Time(s)

puppy-mtcelledit-in-XFCE-ddog-build.png

Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 3599
Location: holland

PostPosted: Thu 10 Aug 2017, 16:27    Post subject:  

Hi all,

@ Andres and wiak
Code:
chroot_in () {

give me this /bin/bash: chroot_in:command not found.


Indeed on Wheezy it got stuck on that for me also.
I suspect that the chroot version from wheezy is too old, doesn't understand: /bin/bash -c <function>

How it's done is like this:
Code:
chroot_in () {
do this
do that
}
export -f chroot_in

chroot chroot /bin/bash -c chroot_in # no go in wheezy


So I tested to change to:
Code:
cat << "EOF" | chroot chroot
do this
do that
EOF


That works in Wheezy but the downside is that no user input is possible in chroot, e.g. got stuck on keyboard config dialog or to set root password.
So modified a little (experimental) to make it run without the user input for the above. (only at the end for compression choice, but that's already out of the chroot)
End result is that the keyboard layout is set to US English by default and the root password is not set (recommended to do so afterwards, btw, when you have booted the live system)
Attached mklive-stretch-mod.gz (remove fake.gz and make executable) so this works on Wheezy also.
(this is at the same time learning experience for my plan to run the script with minimum of user input, at the beginning is OK, but rather not during running)

@ wiak
Very weird indeed the fact that debootstrap does work on (most newer?) puppies and not on Xenialdog.
I've spend a lot of time googling to search for solution, but couldn't find.
I will add cpio to the install commands at the start of script when I make new release.

@zagreb
Quote:
after quick remaster it does not
remain...
what is solution?
regards.

mount -t tmpfs -o "remount,size=130%" tmpfs /mnt/live/memory/changes

One option is to add the line in /etc/rc.local, before the "exit 0"

Fred
mklive-stretch-mod.gz
Description  mklive-stretch-mod (remove fake.gz and make executable) should work from Wheezy
gz

 Download 
Filename  mklive-stretch-mod.gz 
Filesize  17.21 KB 
Downloaded  44 Time(s) 
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 3599
Location: holland

PostPosted: Thu 10 Aug 2017, 17:41    Post subject:  

Hi Belham,

Good to see your enthusiasm ! Very Happy
Besides adding some checkboxes to the GUI and making user input during run as less as possible, I'm not sure what can be done more.
I had in mind a while back to implement different choices for pre-configured desktop environments but that (if possible) will be very complicated and will never be even close to perfect, I guess.
On the other hand, how it is now, the install choices, doesn't work well in all cases, just as example: your xfce setup, it needs fixes that an average user may not know about.

About deb to sfs, I think it's not a good idea, because most .deb packages require dependencies, and people might think easily that creating an sfs from deb will just work, which is not in most cases.
Apt2sfs however does handle dependencies well (but not what you're looking for, i think).

Fred

_________________
Dog Linux website
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1013
Location: not Bulgaria

PostPosted: Thu 10 Aug 2017, 17:52    Post subject:  

Hi Fred and others,

In case you missed my debootstrapDebian project post, you might also like to check out the 'crouton' project murga forum member jd7654 informed me of (and also look at his nice debootstrapDebian-xfce early build attempt within Quirky). Crouton is for chroot Linux inside Chromium OS but the crouton target scripts (for xfce, xfce-desktop, lxde etc) look interesting for extracting build-script additional ideas:

http://www.murga-linux.com/puppy/viewtopic.php?p=963830#963830

http://www.murga-linux.com/puppy/viewtopic.php?p=963838#963838

wiak
Back to top
View user's profile Send private message 
dancytron

Joined: 18 Jul 2012
Posts: 1164

PostPosted: Thu 10 Aug 2017, 17:56    Post subject:  

fredx181 wrote:
Hi Belham,

Good to see your enthusiasm ! Very Happy
Besides adding some checkboxes to the GUI and making user input during run as less as possible, I'm not sure what can be done more.
I had in mind a while back to implement different choices for pre-configured desktop environments but that (if possible) will be very complicated and will never be even close to perfect, I guess.
On the other hand, how it is now, the install choices, doesn't work well in all cases, just as example: your xfce setup, it needs fixes that an average user may not know about.

About deb to sfs, I think it's not a good idea, because most .deb packages require dependencies, and people might think easily that creating an sfs from deb will just work, which is not in most cases.
Apt2sfs however does handle dependencies well (but not what you're looking for, i think).

Fred


I agree with you on the pre-configured desktops. If you do that, you'll multiply the number of little bugs that people will expect you to track down. It will hold the whole thing back. Your script shouldn't try to do that for people. That's what people should do with the script (if that makes sense) and then they can report back what worked.

Two ideas that might make that easier.

First, a log file that shows exactly what the input was for the distribution you just created that someone can post, another person can download, and then paste the exact same choices in to reproduce the other person's build. It might even be a readme.txt file that automatically gets copied to /root/documents that says something like, "This distribution was built with mklive-stretch script revision mm-dd-yyyy with the following [32/64] bit packages: x, y, z etc"

Second, my idea from before, to separate the app's that build the desktop into a separate field so it is easy for people to (for example) delete all the openbox stuff and put lxde, xfce or whatever in its place.

Keep up the great work. This is the most interesting thing I've seen in a long time.

Dan
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1013
Location: not Bulgaria

PostPosted: Thu 10 Aug 2017, 18:08    Post subject:  

dancytron wrote:

I agree with you on the pre-configured desktops. If you do that, you'll multiply the number of little bugs that people will expect you to track down. It will hold the whole thing back. Your script shouldn't try to do that for people. That's what people should do with the script (if that makes sense) and then they can report back what worked.

Two ideas that might make that easier.

First, a log file that shows exactly what the input was for the distribution you just created that someone can post


As I also said earlier, a log file generating capability would be VERY useful.

As for the likes of offering the possibility of pre-configured desktops, one way round that is to use two scripts (the second being an entirely optional plugin, so not even needed by default) - the second script (code plugin) simply being sourced as I note done inside the bash/gtkdialog program wex. Uses very simple code-plugin constructs like:

Code:
   if [ -s "${PROGRAMTMPHOME}/plugins/mp3.plug" ];then
    . "${PROGRAMTMPHOME}/plugins/mp3.plug"
   else
    acodec="libmp3lame"
    avformat="mp3"
   fi # mp3.plug


For example, you could have similar construct like:

Code:
   if [ -s "${HOME}/.mklive/plugins/windowmanager.plug" ];then
    . "${HOME}/.mklive/plugins/windowmanager.plug"
   else
     export BASE_APPS_INSTALL="openbox obconf menu leafpad pcmanfm lxpanel gparted parted pv synaptic volumeicon-alsa alsa-utils viewnior firefox-esr=24.8.0esr-1~deb8u2 pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools conky lxrandr lxinput lxappearance fakeroot xserver-xorg-input-evdev pfind"
   fi # windowmanager.plug


The advantage of doing it that way is that you can still provide your original code after the 'else' statement, but also provide plugin alternatives if you so wished (and let the user do their own support of that if you wish).

wiak
Back to top
View user's profile Send private message 
jd7654

Joined: 06 Apr 2015
Posts: 257

PostPosted: Thu 10 Aug 2017, 18:18    Post subject:  

dancytron wrote:
Second, my idea from before, to separate the app's that build the desktop into a separate field so it is easy for people to (for example) delete all the openbox stuff and put lxde, xfce or whatever in its place.

Keep up the great work. This is the most interesting thing I've seen in a long time.


I second your second. You could kinda follow the modules of porteus for the sections of customization:
000-kernel.xzm
001-core.xzm
002-xorg.xzm
003-mate.xzm
04-firefox.xzm
Separate sections for core, xwin, desktop, apps, and DD and Puppy customizations/scripts.

I think that's what belham was referring to also, their custom iso builder, which just mixed and matched those modules.

Great little project, fulfilled its purpose and more. Anything else is icing on the cake.

Last edited by jd7654 on Thu 10 Aug 2017, 18:34; edited 2 times in total
Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1632

PostPosted: Thu 10 Aug 2017, 18:32    Post subject:  

fredx181 wrote:
Hi Belham,

Good to see your enthusiasm ! Very Happy
Besides adding some checkboxes to the GUI and making user input during run as less as possible, I'm not sure what can be done more.
I had in mind a while back to implement different choices for pre-configured desktop environments but that (if possible) will be very complicated and will never be even close to perfect, I guess.
On the other hand, how it is now, the install choices, doesn't work well in all cases, just as example: your xfce setup, it needs fixes that an average user may not know about.

About deb to sfs, I think it's not a good idea, because most .deb packages require dependencies, and people might think easily that creating an sfs from deb will just work, which is not in most cases.
Apt2sfs however does handle dependencies well (but not what you're looking for, i think).

Fred



Hi Fred,

Understood......I guess I was getting too enthusiastic, sorry for posting so much here. I just see much potential in this, as something that could approach the genuis of what Porteus used to do (as I've discussed before). Oh well, I've hit a brick wall these past two hours----I cannot get budgie to boot. The build script puts together a nice, ~176mg budgie-desktop ISO with the basic budgie core stuff there, but booting is stuck at the command prompt & for the life of me I cannot figure out why. There's no errors listed anywhere up to that point, and even when I get in and check /var/logs, nothing is there indicating a problem. Yet, stuck I am at the command prompt, lol. I got so frustrated, I did a new buld using lumina-desktop, and interestingly, the exact same thing happened. Oh well, it's no big deal....by far the openbox/lxde/flubox and xfce are the nicest builds, and they work. Lastly, plz consider what dancytron, jd7654 and myself are saying about how this script could be a build process somewhat like what Porteus used to be. Before Porteus lost its driving founder, and subsequently went all Slacko & removing the ability of people to simply customize right on their home page with a clickable-build-process, where you literally were watching & waiting a few minutes as your build choices were put together, they were on the track that you & your script are on right now. That's why this is so interesting to me, and why I've been so enthusiastic. So, ok, I'll shutup now and let you scripting geniuses hash stuff out, and I'll lurk in the background for when a new update (if it happens) comes to the buildscript. Then I'll jump back in and be a willing build tester for all. Thanks so much for all your hard work regarding this....first time in a few years, outside of Barry's interesting Easy Linux work, that I've actually been excited about the buildprocess. Woof-CE was grinding me down, the hassles--mostly all needless and pointless---had just become too much. General (not specific) build ustomization in today's age should be a fairly easily process, and your script is doing this. Wink
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 3599
Location: holland

PostPosted: Thu 10 Aug 2017, 19:13    Post subject:  

Thanks guys for the hints and tips.

The separate field for specific Desktop apps and log creation I will surely implement.
About the comparison with Porteus website, that were really choices for a ful pre-configured complete system
As I said earlier, the fields in the GUI are separated only to give a better overview of what the different kind of packages are for basically.

@belham
I say "Good to see your enthusiasm !"
And you say "So, ok, I'll shutup now"
No comprendo Rolling Eyes
If you share details about what happens when you try to run e.g. Budgie or whatever you tested it can be valuable and solutions can possibly be found.
That's what this thread should be for also IMHO !

EDIT: Stuck at the command prompt happend to me also when I did build with XFCE without slim (or any other login-manager e.g. lightdm) so a login manager can solve the problem for Budgie also.
(press F1 once or twice in Slim screen for selecting window-manager or DE)
The point may be that ~/.xsession is still in /root and has inside "exec openbox-session", so possibly conflicts with installed DE

Fred
Back to top
View user's profile Send private message 
AndresC2

Joined: 08 Jul 2017
Posts: 50

PostPosted: Thu 10 Aug 2017, 20:16    Post subject:  

Hello Fred! Very Happy

thanks for your mklive-stretch-mod.

I'm not in linux, try later your script.

Is possible continue from previus downloaded build and not

start fresh? beacause, I have for example, jessie-build with debootstrap

so is not necesary download and build jessie again with debootstrap.

this is optional.
Do you want start fresh build Stretch.
Do you want continue install from previus downloaded Stretch.

by the way:

For lost internet connetion.

#sorry my bad code fix for me please.

apt-get update
[ $? -eq 0 ] && echo -e "\e[0;32mOK\033[0m" || echo -e "\e[0;31mFAILED\033[0m"
if [ $? -eq 0 ]|echo -e "\e[0;31mFAILED\033[0m"; then
read -p "Apt-get FAILED!,do you want try again? ? (Enter=yes) (Y/n)?" choice
case "$choice" in
y|Y|"")
fi

the same for apt-get upgrade and apt-get install, please.

Thanks Fred for all!
very cool project!

AndresC2.
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 12401
Location: Stratford, Ontario

PostPosted: Thu 10 Aug 2017, 21:17    Post subject:  

Here is PeasyScale updated to v2.0.

Remove the fake .gz extension.
peasyscale_2.0_i386.deb.gz
Description 
gz

 Download 
Filename  peasyscale_2.0_i386.deb.gz 
Filesize  10.69 KB 
Downloaded  49 Time(s) 
peasyscale_2.0_amd64.deb.gz
Description 
gz

 Download 
Filename  peasyscale_2.0_amd64.deb.gz 
Filesize  10.91 KB 
Downloaded  49 Time(s) 
Back to top
View user's profile Send private message 
anikin

Joined: 10 May 2012
Posts: 1020

PostPosted: Fri 11 Aug 2017, 05:08    Post subject:
Subject description: "dead" mounts
 

Andresc2 wrote:
. . . some question about this:

proc:device is busy,
dev:device is busy

this happen when not umount binds correctly.

that is better umount binds inside of chroot or outside?

how stop proc:device is busy or
dev:device is busy, after of a bad umount binds?
in console show, try lsof 8 or fuser(1) something like that. . .

I've had so many "dead" mounts . . . I don't have them anymore.

Rule #1: Once you've finished the work in chroot and done the unmounting stuff, * close * all/any terminal windows - very important!

Rule #2: (this step isn't required, but I always do it just to be on the safe side) Drop out of x and do startx again. Go to the chroot directory and if, for some reason there are still any mounted directories, right-click and unmount them manually. Follow these simple steps and you will never have "dead" mounts again. As for unmounting from inside or outside, I just follow to the letter Will Haley's howto.
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 3577
Location: Worcestershire, UK

PostPosted: Fri 11 Aug 2017, 06:00    Post subject:  

I've made my first altered config build - configs below - ....some comments and questions arise:

- would be nice if the configs could be external to the shell-script mklive-stretch.sh (e.g. like DISTRO_PKGS_SPECS in woof-ce)

- can I only include packages from the debian and StretchDog repositories? I'd like to have a local personal repository to pull packages in from (I think)

- how do I add some needed firmware to the build? (may do this using a squashfs in /live/modules rather than in the build....)

- how do I configure the desktop? I've deleted firefox from my build as I want to provide the browser as a squashfs in /live/modules, however the desktop and the panel still have redundant entries

- is the Debian kernel the only one available? what needs to be changed to use other kernels?

Sorry if a lot of questions - the script works fine - just trying to understand how I might use it.

Cheers & thanks
peebee
Code:
export BASE_INSTALL="live-boot wget net-tools ifupdown wireless-tools sysvinit-core xserver-xorg-core xserver-xorg psmisc fuse x11-utils x11-xserver-utils dbus-x11 busybox sudo mawk xinit xterm pciutils usbutils file rsync dosfstools"

export BASE_APPS_INSTALL="lxde openbox obconf menu gparted parted pv synaptic volumeicon-alsa alsa-utils ffmpeg mtpaint pm-utils xdotool wmctrl desktop-file-utils mime-support cryptsetup-bin squashfs-tools conky fakeroot xserver-xorg-input-evdev pfind"

export BASE_DOG_APPS_INSTALL="yad gtkdialog obshutdown pup-volume-monitor frisbee edit-sfs-pcmanfm filemnt-pcmanfm remaster-scripts quick-remaster apt2sfs sfsload fixdepinstall greybird-theme-dd-stretch makedebpackage flashplayerchoice"

_________________
LxPup = Puppy + LXDE

Last edited by peebee on Fri 11 Aug 2017, 07:27; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
rufwoof

Joined: 24 Feb 2014
Posts: 2714

PostPosted: Fri 11 Aug 2017, 06:59    Post subject:  

peebee wrote:
- is the Debian kernel the only one available? what needs to be changed to use other kernels?

Hi peebee. It is useful to better understand the Debian model. Debian "Stable" reflects unchanging ... and not necessarily solid (especially after a new version of 'Stable' is released). In effect a big freeze where the choice of kernel + 50,000 other programs/libs etc. are selected as comprising the set, after which only changes to fix critical errors/security issues are applied to those programs/files.

Debian also have tight entry policies for permitting entrance of programs into their Stable MAIN repositories, as once in Debian maintain that software (fix critical bugs/security issues). You might say 'own' it ... except of course that its open source.

When you understand that you're more inclined to just stick with the core release i.e. Debian "Main" repository for that release. Debian however do cater for "Contrib" and "Non-free" repositories, where contrib contains programs that can have dependencies not inside Debian Main and non-free includes stuff with very little if any Debian control over that.

Personally I've opted to track Debian "OldStable", that a debian stable falls into after a new stable is released. For instance Jessie has recently entered oldstable as Stretch was released. For me running a older desktop PC (approx 9 years old), Jessie is well aligned to that and I can run everything using just Jessie Main repositories. Jessie has been through extensive testing and a further 2 years in general release ... so all 50,000 programs are pretty solid and work well with each other. Debian continue to provide patches for oldstable so lack of security updates isn't a issue. And even whilst a old kernel version ... you have to remember that Debian will have maintained that kernel such that it can be more a case of the kernel being nothing like what its version number suggests it is ... and can be quite 'modern'.

Basically, be mindful before just switching a 'old debian kernel' out for something 'newer'. If you drift from the core set of debian programs like that, debian call it a FrankenDebian and the debian users forum will tend to not support that as it induces instability that sooner or later could break.

Debian oldstable suits me and its unrivalled. For around 2 years I can use a extensive program set provided and maintained by a single provider, receiving updates, and where the collective set of 50,000 repository programs all work well with each other due to in effect having been 'tested' by millions for a couple of years (general release) . Then in 2 years time, I might upgrade to the next oldstable i.e. Stretch, once that has been out in general release for a couple of years and has been superseded by the next general release.

The downside of running oldstable is that oldstable might not work with newer hardware, however you can often pull back versions of programs from later releases that may very well work with newer hardware ... which they call 'backporting'. That could however induce instability as you're running a bit of a Frankendebian in doing that, however this is where Puppy like structure can fit in nicely ... as the backports could be stored as SFS's that can be easily unloaded to leave a core/main sfs (like puppy_xxx.sfs) of perhaps just debian jessie content.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 13 of 96 [1434 Posts]   Goto page: Previous 1, 2, 3, ..., 11, 12, 13, 14, 15, ..., 94, 95, 96 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1914s ][ Queries: 13 (0.0371s) ][ GZIP on ]