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 17 Sep 2014, 09:33
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Alternative way to build Ubuntu / Debian Puppy
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 8 [109 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
Author Message
mavrothal


Joined: 24 Aug 2009
Posts: 1615

PostPosted: Fri 06 Jun 2014, 02:42    Post subject:  

Iguleder wrote:
Looks good. I really wonder how big it is with all Puppy applications, before cleanup.

With firefox is ~170MB (gzipped SFS) Abiword/Gnumeric and friends pulls a lot more though.

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send private message 
jamesbond

Joined: 26 Feb 2007
Posts: 2155
Location: The Blue Marble

PostPosted: Fri 06 Jun 2014, 03:10    Post subject:  

mavrothal wrote:
Iguleder wrote:
Looks good. I really wonder how big it is with all Puppy applications, before cleanup.

With firefox is ~170MB (gzipped SFS) Abiword/Gnumeric and friends pulls a lot more though.


That's because Abiword and Gnumeric depends on GTK3 Evil or Very Mad So for these kind of apps, you need to build GTK2 versions and package them into DEB and upload to own repo. And you can bump up the compression by using "-comp xz -Xbcj x86" instead of the default "-comp gzip" I have in my sample pkglist. It will still be big, though.

Another trick is this - you can attempt to turn off dependency (%nodepend) and install the package and its dependencies manually, with you choosing only the deps you want to install (this is no fun, but works). Or, you can keep dependency checking on, but later you %remove the packages that you don't need. Some of the dependencies are really not needed (e.g. udev pulls a crap load of dependency, which I ignore with %nodepend, and it still works).

Of course, the success of this depends on the package itself. With some packages, the depedencies are really with loadable modules/plugins - if you don't include the dependencies, those plugins won't work but the main application still work. Some packages, however, have dependencies compiled built into them - with these kind of packages you're really out of luck.

With abiword/gnumeric which depends on gtk3, you don't really have an option other than pulling all those gtk3 stuff Confused I'd recommend making our own DEBs for these as they are not core to the system. (Xorg, however, is core, and we should keep parent distro's one).

indicative only wrote:
# grep systemd repo-trusty-i386/pkgdb | wc -l
58
# grep libgtk-3 repo-trusty-i386/pkgdb | wc -l
540
# grep libgtk2 repo-trusty-i386/pkgdb | wc -l
1329


I'm very troubled with the fact that synaptics depends on gtk3, I hope there is a way to build it to depend on gtk2. Aptitude-gtk is dead, and aptitude-ncurses depens on .... python?! Any other GUI front-end to apt? Confused

Quote:
Also, rootfs-skeleton is a mess. It clutters the main SFS with so many files.
Laughing
Don't like it? Here's a trick: Mavrothal asked me to add support for installing rootfs-packages, which I did. I now have another purpose for that "rootfs-packages" - how about we make a package called "myown-rootfs", and in the pkglist we don't do %addbase but instead to "%addpkg myown-rootfs" Twisted Evil
I had an example called james-mods which replaced xwin with a simpler variant, and replaces xorg-wizard, but nothing is stopping you to supply a full rootfs there Twisted Evil I you look inside deb-build.sh, the code handling %addbase and %addpkg is identical Twisted Evil Twisted Evil

_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 1615

PostPosted: Fri 06 Jun 2014, 03:48    Post subject:  

jamesbond wrote:

With abiword/gnumeric which depends on gtk3, you don't really have an option other than pulling all those gtk3 stuff Confused I'd recommend making our own DEBs for these as they are not core to the system. (Xorg, however, is core, and we should keep parent distro's one).

indicative only wrote:
# grep systemd repo-trusty-i386/pkgdb | wc -l
58
# grep libgtk-3 repo-trusty-i386/pkgdb | wc -l
540
# grep libgtk2 repo-trusty-i386/pkgdb | wc -l
1329


I'm very troubled with the fact that synaptics depends on gtk3, I hope there is a way to build it to depend on gtk2.

According to the synaptic home page it needs gtk+2.4 (or latter).
But distro compatibility and size will be a continuous battle that we can not win with 2-3 people behind puppy. Specially if we do not want to employ BK's elaborate "templates" system and mixing distro and non-distro binaries.
But I think for now lets try to get a fully blown system and see how does it do size, efficiency and functionality wise.
BTW would be handy to either utilize the puppy kernels (since the build scripts are there too) or provide a 32bit "fatdog-like" kernel (sorry too little time these days Sad )

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 7801
Location: qld

PostPosted: Fri 06 Jun 2014, 04:33    Post subject:  

Perhaps puppy typical gtk2+ programs (ie compiled light as possible) could go in a separate sfs (adrv?) and therefore not registering with dpkg. However that recreates an age old problem of stuffs in sfs not registering with package management. That could be addressed in a native package manager but then that defeats the purpose of this project.

The end user doesn't give a toss. Well, they toss the CD if it doesn't "just work". Likewise they don't want to know about terminals. A gtkdialog or gtkbuilder frontend for apt? Sounds scary/crazy eh?

_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send private message Visit poster's website 
jamesbond

Joined: 26 Feb 2007
Posts: 2155
Location: The Blue Marble

PostPosted: Fri 06 Jun 2014, 09:36    Post subject:  

mavrothal wrote:
Specially if we do not want to employ BK's elaborate "templates" system
I don't know what you mean by this. What is this "template" system?
Quote:
and mixing distro and non-distro binaries.
I think this can't be avoided. Xdialog and gtkdialog already comes from ourselves. Synaptic will probably have to be our own too (thanks for pointing this out), and so will abiword/gnumeric be if we want to have them in reasonable size. But they must be done in the proper native package format so they get recorded. DEBs for Debian/Ubuntu, TGZ/TXZ for slackware, etc.
Quote:
BTW would be handy to either utilize the puppy kernels (since the build scripts are there too) or provide a 32bit "fatdog-like" kernel

We don't need fatdog-like kernel, I did it just so I can quickly come up with a script that builds an ISO. Puppy's traditional initrd has a mixture of kernel modules in initrd and in basesfs. This is complicated, we need to copy some modules to initrd, do depmod, then copy the rest and firmware to basesfs, etc. This can still be done (although I don't provide the tool to do that), and the resulting puppy will still work.

So to simplify matter, I put *ZERO* modules in initrd. That's right, there is no modules in initrd. This makes the initrd, in a sense, "universal"; it can be used for any puppies. I use ZDRV exclusively to load kernel modules (kernel-modules.sfs). Basesfs (puppy.sfs) is free from kernel modules, and thus is universal too. If you want to update kernel, just update vmlinuz and kernel-modules - then you're done. No complicated unsquashfs/mksquashfs, no uncomplicated extracting initrd and rebuild.
For this to work, the kernel must be compiled with enough kernel modules to be able to find ZDRV and load it. It means loopback, aufs, squashfs, filesystem drivers, usb drivers (if we want to boot from usb) *must* be compiled to the kernel, not as a module. That's all there is to it. If puppy's kernel is currently compiled with that, then it should be straightforward to download puppy's kernel and build the ISO. Otherwise, either the kernel config needs to be modified, or we need to use standard puppy initrd build as above.

Quote:
Perhaps puppy typical gtk2+ programs (ie compiled light as possible) could go in a separate sfs (adrv?) and therefore not registering with dpkg. However that recreates an age old problem of stuffs in sfs not registering with package management.
I personally think there isn't a problem with that. Apps in SFS, by its nature, ephemeral, they can be added or removed at anytime. So I don't see the need for them register with the native package management, and in general, it is not good for regular programs to depend on presence of such SFS.

That being said, if you really want to integrate them, for dpkg this is going to be a bit difficult (not impossible, but difficult). In slackware system, the installed packages are recorded in individual manifests in /var/log/packages. To give an appearance of an "installed" package, all you need to do is add one more package manifest in that directory and that package will be "installed." In dpkg, this is not that easy - packages are recorded in two places, one individual manifest like slackware in /var/lib/dpkg/list, one in big giant database called /var/lib/dpkg/status. It is the latter which gives us headache. But it is still possible - however, one needs to agree on having a "post-load" and "pre-remove" scripts to be run on SFS load/removal; and that script will be responsible to manipulate /var/lib/dpkg/status.

Quote:
That could be addressed in a native package manager but then that defeats the purpose of this project.
A package manager which doesn't come from the parent has two problems.
1) It always suffers from "translation" problem. And as usual when translating something, some information or some context may be lost, which *may* cause issues later. That's the reason to stay with parent distro's manager.
2) Then there is this "current-ness" problem. How to know whether the cached, translated package database is not out of date compared to the parent distro's native package database?
Both of these are not intractable problems, and can be addressed (as the current PPM obviously shows), but they are still quite challenging nonetheless.

Quote:
The end user doesn't give a toss. Well, they toss the CD if it doesn't "just work". Likewise they don't want to know about terminals. A gtkdialog or gtkbuilder frontend for apt? Sounds scary/crazy eh?
Not scary, but with the number of packages around ~44,000, you do need crazy optimisation to make gtkdialog fast Wink
_________________
Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1906
Location: Israel, somewhere in the beautiful desert

PostPosted: Fri 06 Jun 2014, 13:21    Post subject:  

Makes sense.

So ... now it's time for us to set up an Apt repository?

There's an alternative - merging Puppy-specific packages into rootfs-skeleton.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
stemsee


Joined: 27 Jun 2013
Posts: 362
Location: London

PostPosted: Fri 06 Jun 2014, 16:22    Post subject: kernel
Subject description: localyesconfig
 

jamesbond wrote:
For this to work, the kernel must be compiled with enough kernel modules to be able to find ZDRV and load it. It means loopback, aufs, squashfs, filesystem drivers, usb drivers (if we want to boot from usb) *must* be compiled to the kernel, not as a module. :


What is the reason for not having all modules built-in to the kernel? The kernel should have better performance too.
Back to top
View user's profile Send private message MSN Messenger 
Keef


Joined: 20 Dec 2007
Posts: 628
Location: Staffordshire

PostPosted: Fri 06 Jun 2014, 16:34    Post subject:  

Doesn't "localyesconfig" select the modules just for the current running system?
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1906
Location: Israel, somewhere in the beautiful desert

PostPosted: Fri 06 Jun 2014, 16:40    Post subject: Re: kernel
Subject description: localyesconfig
 

stemsee wrote:
jamesbond wrote:
For this to work, the kernel must be compiled with enough kernel modules to be able to find ZDRV and load it. It means loopback, aufs, squashfs, filesystem drivers, usb drivers (if we want to boot from usb) *must* be compiled to the kernel, not as a module. :


What is the reason for not having all modules built-in to the kernel? The kernel should have better performance too.


They're huge - a kernel package is ~50 MB with the modules. This means, the distro RAM usage starts at the uncompressed size of the kernel package.

Having all the modules in the main SFS doesn't have any downsides. A kernel with all the modules jamesbond specified should be 2-3 MB.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
stemsee


Joined: 27 Jun 2013
Posts: 362
Location: London

PostPosted: Fri 06 Jun 2014, 16:43    Post subject:  

yep, make sure everything is on! ... then after run make menuconfig and modify accordingly! Might save some time!
Back to top
View user's profile Send private message MSN Messenger 
gcmartin

Joined: 14 Oct 2005
Posts: 4275
Location: Earth

PostPosted: Fri 06 Jun 2014, 16:54    Post subject:  

Questions:
  • In 2014 is GTK3 all that bad for this new build tool?
  • Would life be simpler for the march into the future if we embraced it now?
Everyone knows I am not a developer, merely a testor-user.

Curious

_________________
Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engine or use DogPile
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 1615

PostPosted: Sat 07 Jun 2014, 02:33    Post subject:  

Just generated the woof-next branch in woof-CE.
Basically moved all woof building scripts to woof-code/woof2-scripts_and_files and changed merge2out not to copy over all the distro-package-...
It does not have jamesbond's changes so it can not build anything right now, but does have jamesbond as a woof-CE member Wink

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 7801
Location: qld

PostPosted: Sat 07 Jun 2014, 03:16    Post subject:  

Soon I'll work on modifying kernel kit to package the modules in an sfs (zdrv) so we can make use of the simple fatdog style initrd. Anyone think of anything else to be into the kernel image? So far we have squashfs, aufs, ext2,3,4, .....other fs? Really "other fs" can be up to the builder; eg: if one wants to try booting from hfs+ then that must be a builtin. Same for reiser, btrfs, f2s etc.
_________________
Woof Mailing List | keep the faith Cool |
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 1615

PostPosted: Sat 07 Jun 2014, 04:01    Post subject:  

01micko wrote:
Soon I'll work on modifying kernel kit to package the modules in an sfs (zdrv) so we can make use of the simple fatdog style initrd. Anyone think of anything else to be into the kernel image? So far we have squashfs, aufs, ext2,3,4, .....other fs? Really "other fs" can be up to the builder; eg: if one wants to try booting from hfs+ then that must be a builtin. Same for reiser, btrfs, f2s etc.

VFAT for sure.
f2fs if possible too.
What about booting from NTFS volumes?
Although is sacrilegious to run linux in a Mac ( Shocked Razz ) there is a bunch of 32bit intel core duo (not core2duo) Macs that are stuck with OSX 10.6 and not supported anymore. So go for it.
I guess the other question is SCSI/IDE/SATA etc.

Another option would be to have the entire kernel in the initrd so you do not really need to wary about what is where. XOpup does that but it has really few modules.
Should not really affect boot times since this file will be loaded from somewhere and will likely decrease the kernel memory since a bunch of unused modules will not be in vmlinuz.

_________________
Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too Very Happy
Back to top
View user's profile Send private message 
Iguleder


Joined: 11 Aug 2009
Posts: 1906
Location: Israel, somewhere in the beautiful desert

PostPosted: Sat 07 Jun 2014, 05:14    Post subject:  

All we need is:
- Drivers for USB mass storage devices
- All hard drive drivers (they're tiny)
- SCSI CDROM drivers
- Drivers for all file systems we want to be able to boot from - ext2, ext3, ext4, FAT16/32, NTFS (?), XFS, reiserfs (for unlucky users who installed an old distro and kept the file system when they moved on to Puppy) and btrfs ... isn't f2fs too young?
- Squashfs and Aufs

This is the classic Puppy recipe - it should produce a 2-3 MB kernel.

I think sticking to a LTS kernel is the way to go, because pretty often, Aufs gets messed up with the latest and greatest (segfaults, in the kernel Crying or Very sad ). I've been using 3.10.x since it received its LTS status and it's simply awesome.

EDIT: 01micko - here's my kernel building script for 3.10. It's very Puppy-like, except the fact it's for Linux-libre and doesn't have Aufs. It took some time and additional gray hair to get UEFI to work (i.e, it boots but you get a black screen because it doesn't have the UEFI framebuffer module Laughing ), so it's a good reference configuration.

EDIT 2: I have a static toybox and many static daemons I wrote on my own (i.e syslogd and klogd). Functionality-wise, they should be compatible with the BusyBox ones. Maybe we could use them in the initrd instead of BusyBox. They're much lighter and smaller.

_________________
My homepage
Back to top
View user's profile Send private message Visit poster's website MSN Messenger 
ICQ Number 
Display posts from previous:   Sort by:   
Page 2 of 8 [109 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
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.1160s ][ Queries: 12 (0.0046s) ][ GZIP on ]