The time now is Mon 09 Dec 2019, 03:59
All times are UTC - 4 |
Page 13 of 103 [1533 Posts] |
Goto page: Previous 1, 2, 3, ..., 11, 12, 13, 14, 15, ..., 101, 102, 103 Next |
Author |
Message |
belham2
Joined: 15 Aug 2016 Posts: 1707
|
Posted: Thu 10 Aug 2017, 15:02 Post subject:
|
|
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
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
|
|
 |
belham2
Joined: 15 Aug 2016 Posts: 1707
|
Posted: 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.
Description |
|
Filesize |
217.02 KB |
Viewed |
729 Time(s) |

|
|
Back to top
|
|
 |
fredx181

Joined: 11 Dec 2013 Posts: 4204 Location: holland
|
Posted: 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
Description |
mklive-stretch-mod (remove fake.gz and make executable) should work from Wheezy
|

Download |
Filename |
mklive-stretch-mod.gz |
Filesize |
17.21 KB |
Downloaded |
69 Time(s) |
|
Back to top
|
|
 |
fredx181

Joined: 11 Dec 2013 Posts: 4204 Location: holland
|
Posted: Thu 10 Aug 2017, 17:41 Post subject:
|
|
Hi Belham,
Good to see your enthusiasm !
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
Tinylinux blog by wiak
|
Back to top
|
|
 |
wiak
Joined: 11 Dec 2007 Posts: 1842 Location: not Bulgaria
|
Posted: 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
|
|
 |
dancytron
Joined: 18 Jul 2012 Posts: 1413
|
Posted: Thu 10 Aug 2017, 17:56 Post subject:
|
|
fredx181 wrote: | Hi Belham,
Good to see your enthusiasm !
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
|
|
 |
wiak
Joined: 11 Dec 2007 Posts: 1842 Location: not Bulgaria
|
Posted: 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
|
|
 |
jd7654
Joined: 06 Apr 2015 Posts: 297
|
Posted: 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
|
|
 |
belham2
Joined: 15 Aug 2016 Posts: 1707
|
Posted: Thu 10 Aug 2017, 18:32 Post subject:
|
|
fredx181 wrote: | Hi Belham,
Good to see your enthusiasm !
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.
|
Back to top
|
|
 |
fredx181

Joined: 11 Dec 2013 Posts: 4204 Location: holland
|
Posted: 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
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
|
|
 |
AndresC2
Joined: 08 Jul 2017 Posts: 76
|
Posted: Thu 10 Aug 2017, 20:16 Post subject:
|
|
Hello Fred!
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
|
|
 |
rcrsn51

Joined: 05 Sep 2006 Posts: 12801 Location: Stratford, Ontario
|
Posted: Thu 10 Aug 2017, 21:17 Post subject:
|
|
Here is PeasyScale updated to v2.0.
Update: The binary tool get-image-size has been added to the package. It is now used by other apps that have PeasyScale as a dependency.
Remove the fake .gz extension.
----------------
Description |
Updated 2019-02-21 Fix for ".jpeg" extensions
|

Download |
Filename |
peasyscale_2.1_i386.deb.gz |
Filesize |
11.66 KB |
Downloaded |
32 Time(s) |
Description |
Updated 2019-02-21 Fix for ".jpeg" extensions
|

Download |
Filename |
peasyscale_2.1_amd64.deb.gz |
Filesize |
11.83 KB |
Downloaded |
33 Time(s) |
Last edited by rcrsn51 on Thu 21 Feb 2019, 07:44; edited 5 times in total
|
Back to top
|
|
 |
anikin
Joined: 10 May 2012 Posts: 1020
|
Posted: 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
|
|
 |
peebee

Joined: 21 Sep 2008 Posts: 4091 Location: Worcestershire, UK
|
Posted: 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
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Last edited by peebee on Fri 11 Aug 2017, 07:27; edited 1 time in total
|
Back to top
|
|
 |
rufwoof

Joined: 24 Feb 2014 Posts: 3671
|
Posted: 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
|
|
 |
|
Page 13 of 103 [1533 Posts] |
Goto page: Previous 1, 2, 3, ..., 11, 12, 13, 14, 15, ..., 101, 102, 103 Next |
|
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
|